Archive for the ‘Uncategorized’ Category

The e in e-Government

February 16, 2008

E-government traditionally refers to the delivery of government information and services online. The web presents governments with cost effective ways to reach out to the public and governments at all levels have placed a wide range of materials on the web from publications to databases. But e-government offers governments the opportunity to listen as well as to speak. I would argue that the full potential of e-government will only truly be realized when the ‘e’ in e-Government stands for ‘engagement’ rather than ‘electronic’.

Email allows citizens to interact with government officials or request information or services. While email is certainly the easiest method of contact, there are other methods that government websites can employ to listen to the public. These include areas to post comments, the use of message boards, and chat rooms. Websites using these features would allow citizens and department members alike to read and respond to others’ comments regarding issues. Survey tools, polls and petitions could be used as could blogs and Wikis.

Citizens bring diverse perspectives and experiences to e-government, and government would benefit from citizen suggestions, complaints, and feedback. Even a simple feature such as a comment form empowers citizens and gives them a voice.

Business has learned to leverage electronic services to create new paradigms with its customers. Self-Service, online order entry and online support are all examples of business shedding expenses in exchange for putting consumer’s in control. Experience from e-businesses shows that the identification of customer needs is an iterative process involving interactions of various forms. Government must learn to do the same and the next wave of e-government must move towards building engagement with the public so that the public use services through new channels, not because they save the government money but because they are more efficient and effective.

The debate over web personalization vs privacy will continue for the foreseeable future. Technology, and the ability to target and respond to an individual’s needs clashes with the individuals right to forbid others from getting too much information about their behavior. Privacy advocates will continue to raise concerns about the use of technologies but once we solve the problem let’s hope that technology will be used to encourage participatiion by citizens rather than simply make existing processes faster or worse spread existing poor ones.

 

Devide and be Conquered

February 13, 2008

In the beginning life was simple: there were Analysts and Developers. Analysts acted as Project Managers if they needed to and Developers provided what administration was needed (system, network, database). What little administration was required was done in a timely manner, in response to the needs of the project. At some point in time a trend towards specialization took over. Suddenly we need Network Administration, Server Administration, Security Administration, Storage Administration, Backup Administration, Database Administration, Deployment Administration and of course the glue that holds it all together Administration Administrators. Today many IT directors in a large corporations are surrounded by an entourage of software administrators all working hard to make them as paranoid as possible about needing their skills.

This fragmentation has had some seriously negative consequences including increased communication, more dependencies, decreased agility, more staff and the ever popular process, procedure and paperwork.

The cost of supporting all these administrative roles has exploded. The upside is that it has created management roles for many. The downside is that it slows project progress. On a daily basis I hear developers cry some form of “WTF” or “I can’t believe this…”.

My view of Database Administrators is polarized. More so than ever before I view databases as an integral part of an automated system. DBAs who understand the details of the database engines and are willing to participate in developing a system are worth their weight in gold. They are in essence developers and an integral part of a development team.

However, there is a special breed of DBAs who have blossomed in large corporations who don’t understand this role. Their authority comes from owning database permissions. They frown at the thought of creating or altering a table. Try “evolving” a physical database design in some organizations. How can you experiment when every change must be justified to a DBA who then will have you wait while they reluctantly schedule the change for you. 

Much of the large corporation inefficiency in software development comes from administrators who have been given too much power, and often take up adversarial positions against development teams.  This isn’t something that can be fixed easily because there’s often a deeply rooted culture of control and change prevention.

It’s no wonder that so many large corporations outsource their major projects.

Product Management

March 11, 2007

Developing products is an important part of what Thinknostic is all about. We build commercial software products for our clients as well as develop our own product ideas. The product development process both energizes and invigorates us by encouraging us to use techniques we might not otherwise use and apply disciplines we might not otherwise have.

Creating a new product requires inspiration, innovation and a keen sense of what consumers want. This is where Product Management begins. The term “Product Management” seems to mean different things to different organizations. I like to think of the role as being the primary liaison between the software team, the marketing team and the business team. In many cases the Product Manager may have been recruited from or asked to also lead one or more of those teams and this might explain why the role has no universally accepted definition.

First and foremost the Product Manager is a representative for the products market for all important team decisions. It also involves acting as a liaison between the software team when dealing with customers and acting as a representative of both when dealing with the business and financial side of things.

The Product Managers accountability is to deliver the right product. That means they are trying to delivery maximum value to the customers. The Project Managers accountability is to deliver the product right. That means they will be striving for defect free code, delivered on time and to budget. These roles are co-dependent and their goals should be complementary however there are times when trade-offs need to be negotiated. For example incorporating new features late in the delivery cycle can jeopardize the availability date, destabilize the code or blow the budget. On the other hand not having the feature might mean losing an important customer or missing a new market segment. The most critical part of Product Management is figuring out who your customers are, and what they need.

How we fit Product Management into thinkWRAP

At Thinknostic we aim for commercial quality at prototype speed. This means short release cycles and quick rapid feedback. Neither ours nor our customers budgets are unlimited so our focus must always be on maximizing customer value and that means that our product managers need to be priority setters. They must be very effective at information gathering, synthesis and dissemination so that opportunities to improve consumer value can be quickly assessed, prioritized and communicated to the development team.

There are many aspects of thinkWRAP that make the Product Management discipline even more important. There is a need to get an up-front understanding of the products value as perceived by the consumer, and continually validate and refine that throughout the project. Priorities must be adjusted as our perception of reality evolves. A thinkWRAP project treats completion dates and budgets as fixed unless the business decides otherwise. That makes scope or features the major variable. Deciding which features provide the maximum value requires extensive customer input, experience and sound judgement throughout the project. That is the core responsibility of the Product Manager.

On Coaching

March 11, 2007

I’m starting a new activity: visiting Universities with my oldest son. He’ll be finishing high school this year and is trying to decide where he wants to go to school next year. When I was his age it never occurred to me to visit a school. I felt I could learn everything I needed to learn from a brochure but my son is different from me. He wants to absorb the feel of the campus and have a first-hand look at the facilities before he makes his decision. What will be difficult for me as a parent is knowing when to speak and when not to so that he makes his own decisions.

The when-to-shut-up problem is the same problem that managers encounter when coaching or mentoring at work. When coaching, it’s often much better to allow the coachee to brainstorm, and evaluate their options, rather than imposing the coach’s perspective. Telling people what to do or doing it for them is not coaching. It’s very ackward because coaches and mentors are often chosen for the experience they have. Denying that experience can be difficult to do but sometimes it’s for the best.

In this case my son needs to make his own decisions. He needs to develop the criteria by which he can evaluate his options. I am helping by suggesting a few things, and by asking a few leading questions but I can’t answer those questions for him. Providing my opinions all the time would be imposing my help. So I’ve been working on asking open-ended questions and asking about decision criteria. I have even suggested he develop a budget. Mostly I am practicing at nodding a lot. It’s a little difficult, because I have strong opinions but I’m getting better at it.

If you’re coaching someone, make sure you think about when to speak and when to be quiet. It may not be difficult for you but make a conscious decision for the good of the coaching relationship and for the coachee. It’s worth it in the long run.

Managing Change

March 5, 2007

Experience teaches me that the formula for a successful software system implementation has three critical elements:  technology, process and people.  Successful projects factor all three of equally important aspects of the technology-induced change.

As an IT consultant who manages the implementation of business systems I’m often exposed to communities of system users who experience change anxiety in their work environments. Even when warned of the impending changes, and with many of them actually contributing to the process, the change is often overwhelming to impacted users. If the situation is left unmanaged the cries for things to go back to the way they were can start long before the implementation.  The impacts on the software project can be devastating.  The impact on staff and morale can be worse. 

So why does this happen ? The reasons are as diverse and the changes themselves and too dependent on local context to be captured in one model but some of the recurring themes are:

  • Loss of control, lack of flexibility, loss of power.
  • Fear of the unknown, forced learning, change in routine.
  • Fear of looking “foolish”
  •  Loss of relevance of formerly valued knowledge
  • Bad past experiences

As an IT project manager I have learnt that system adoption is a risk factor that must be accounted for and managed. Even if the there is no question that a change is required, it could (and often is) resisted.  You know you have not managed change when the level of resistance far exceeds the magnitude of the change.  

So how do we manage this change?   In a word communicate.  The trick is to know what to communicate, to whom, how and when. 

How do you know you’ve won

February 27, 2007

What constitutes success of a project? The common answers I get to this question generally focus on the project deliverables and whether these are on time, to cost and to specification.   But can a project be a true success if the planned business outcomes are not realized. Can we reliably trust that by producing the deliverables on time and on budget that business value will be generated ?

I try to expand the traditional view of project success to include the achievement of specific business outcomes. Delivering Benefits, to the sponsoring organization should be the sole purpose of any project. Every project starts out with good intentions and a plan to deliver what its sponsors think they need. But too often the benefits everyone expects are promptly laid aside when the project work begins.  This focus is then replaced with a focus on producing deliverables on time and on budget.  Even if they take the time to clearly define their goals, many companies stop short of testing their assumptions to determine whether the goals can realistically be achieved.  Some teams become so obsessed with producing deliverables that they become blind to the fact that those deliverables may fail produce the intended benefit.

Benefits management requires planning and constant testing of the assumptions that create the benefits at each stage in a project’s life cycle, not just at the end.  This allows managers and project teams to take corrective action or refine the expected benefits, based on interim results. A structured approach to defining and monitoring a project’s benefits ensures that the promises made in the business case actually do materialize.

Don’t get me wrong, I get that being on time and on budget is a good thing, but it’s not the only thing.

Multi-Heritageism

October 21, 2006

Today the Thinknostic project team celebrated Diwali.  In India Diwali is a 5 day festival that celebrates life and hope for mankind.  Known as the festival of lights the 5 day festival features fireworks, great food and the strengthening of relationships. I am not from India, in fact only one member of our team is.  But that did not matter to the twelve of us as we took a mid-afternoon break and gathered outdoors in a rain shelter on a cold, windy and wet fall day to light sparklers and enjoy a snack together.  It was wonderful ! 

I was reminded once again of the many heritages that make up our team.  We have representation from many nations, several continents, both genders, a few religions, perhaps a dozen languages, different eye, hair and skin color, many points of view as well as varying heights and weights.  It’s a veritable United Nations except that unlike the UN we work very well together.  As individuals we may represent many different heritages but as a team we are building a single workplace culture.  It will be fun to watch it develop.

 

Happy Diwali.  

Thank You

September 29, 2006

Someone thanked my project team this week.  Someone other than me.  THE someone, the one who counts, their CIO.  The thank you was a good one.  It was sincere, honest and backed by specific facts that could be directly attributed to the team.  It was well delivered and the effect has been instantaneous and nothing short of magical: 

  • Sarcasm and cynicism is at an all time low
  • Focus and sense of purpose is at an all time high
  • Interpersonal differences have been set aside
  • They now smile more often and easily
  • Personal calls are shorter, water cooler discussion is about work
  • Productivity is up, in a big way
  • They rediscovered curiosity and spontaneously began exploring  new features of the products they manage  

I know the affect won’t last forever but I’m enjoying it while I can.  I learned about the power of saying thanks from a very wise man who mentored me many years ago.  It’s now part of my project management toolkit – filed under Magic Tricks right beside Pulling Deliverables out of a Hat.   It’s inexpensive and massively powerful tool if used judiciously and honestly.  I have considered it a distinct competitive advantage but I see the secret is getting out.  Try it and let me know if it works for you.   

On hiring, golf and character

September 28, 2006

I have been asked by one of my clients to assist in hiring a team leader. I was presented with a scripted list of interview questions to review. They seemed to adequately test the candidate’s technical proficiency, management skills, and domain acumen but as is often the case this questionnaire lacked in terms of assessing the candidates character and overall fit into the team. This would yet again be left to instinct. I do trust my instincts but there is a better way.

I don’t know who said it first but the saying goes “golf does not build character’, it reveals it.” As a long time and formerly very active golfer who has participated in business golf, recreational golf and competitive golf I have been exposed to, and gained tremendous insight into how golf can reveal much about a person’s character. Unlike the office setting – the golf course affords you have a chance to observe a person’s decision making process, reasoning and problem solving ability by observing their course management, club and shot selection. You can learn much about their temperament by observing their responses to outcomes. These all reveal important aspects of character including: patience, integrity, temper, modesty, consideration, honesty, competitiveness, logic, wisdom, reason and ego.

I consider myself to be a student of the game of golf and have observed the golf swings of many dozens of people I know well. I have learnt that a persons golf swing (regardless of level of ability) reveals much about an individual, specifically: are they results or process oriented, methodical, quick, even tempered, curious, consistent, ambitious, aggressive, etc…

The great golfer Ben Hogan was known for being one of the few golfers ever who truly owned his golf swing. In his book Five Lessons, The Modern Fundamentals of Golf he defined character as , “… a set of fundamentals that appeared to me to be right because they accomplished a very definite purpose, a set of fundamentals that proved to me they were right because they stood up and produced under all kinds of pressure.”

Observing prospective employees or clients on the course will allow you to see them in a different light.

Sadly will not be presented with an opportunity to golf with the candidates for this position and will instead have to devise other tests that will simulate real work situations and help expose character the way a game of golf would.