Yesterday, I addressed Technologists regarding Project Success; today I address Stake-holders.
I have participated in projects that have succeeded and in projects that have failed. One thing I noticed about the failed projects: expectations were poorly - or not - managed.
What are examples of project expectations?
- Functionality - when completed, the application / upgrade / database / server will allow me to perform xyz.
- Time - how much time one expects to develop the functionality. Can also include a schedule for deliverables and / or milestones.
- Expense - how much one expects to pay for the functionality.
As a stake-holder you know what you want. And you can probably communicate your expectations - using the three areas above as a guide - effectively. Issues arise when, for whatever reasons, there is a disconnect between your expectations and the those of the IT team tasked with performing the work.
I've witnessed several unsuccessful executive responses to the disconnect scenario:
- "Ostritch" - ignoring the disconnect in hopes it will disappear with time.
- "Gambler" - belief that there's a big score (project or technical break-through) just-around-the-corner that will save the day.
- "Taskmaster" - belief that threatening people is the way to motivate them to work around challenges.
- "More-Resources" - a firm belief that more resources can solve any problem known to humanity. (I often imagine these folks live in subdivisions and get their neighbors to help mow their lawns. In my mind I see forty push-mowers aligned wheel-to-wheel along one edge of a lawn. On signal, they all puch across the lawn, mowing it from end to end in a single pass...)
I worked for a company that decided to employ Performance-Based Management techniques to a successful team. They actually applied the concept company-wide, regardless of whether the teams were successful or not. In this particular flavor of PBO, 20% of employees were considered outstanding, 60% were satisfactory, and 20% were acceptable losses that the company would be better without. These numbers were set in stone and never changed.
My questions were:
- Who failed? Did HR fail 80% of the time by hiring mediocre to poor employees? or did our management disillusion and de-motivate these people into their non-excellent state?
- Are we, in effect, planning to never get better?
Statistical control works on processes, not people - at least not well on people.
So what is the solution?
Communication.
It's that simple. Executives have to either be approachable by the IT team or someone representing them, or you must appoint someone to be approachable in your stead. Leadership dynamics (or just plain scheduling issues) may require you to appoint someone. If so, try to find someone who speaks both business and technology.
Realize that sometimes you do not know what you do not know. I run a couple small corporations and have an appreciation for the amount of work involved in merely administering such an entity. I also know technology changes every day. It's difficult for anyone to keep up - especially if you're minding stock-holders, regulators, and the lot. We may have moved beyond the technology you understand. If we haven't, we will soon.
Either hire people you trust or trust the people you hire. If someone violates the trust, respond accordingly. But do everything within your power to exude trust-worthiness as well as trusting-ness.
For truly innovative people to be free to succeed, they must first be free to fail.
The best tools were once toys. IT professionals are notorious tinkerers. You will be astonished at the return on investment for a weekly-scheduled hour of "play time" for developers.
:{> Andy
Technorati Tags: Software projects Success Failure Technologists