On a project planning board on a wall, I recently saw this task:
That is something that is easy to say in a meeting, but this is not a task. It is an amorphous blob of worry that nobody is going to do anything about, but everybody will feel bad about.
A real task is something that someone can actually do. If you really need to check all the interfaces, the first task in the “interface checking” sub-project is to write a list of all interfaces. That is a task you can assign to someone.
I’m currently estimating the effort for a piece of software. With 20 years of experience under my belt, I don’t find estimating hard any longer. But back when I started out, I was terrified whenever I was asked to provide an estimate.
In most organizations, too much of the estimating is art and too little is science. Experienced developers can produce good, realistic estimates, but these are often treated as individual efforts and no organizational learning takes place.
For every estimate, you should capture the requirements and the estimate in an estimation database. This will allow less experienced colleagues to browse this database for something that looks like the task they are asked to estimate, and provide a reality check for their numbers.
When people take on home renovation “Do-It-Yourself” projects beyond their skills, disaster ensues. Apparently, this is so common that you can base a whole TV series on this theme – where professionals rescue the disastrous DIY project for the grateful and clueless amateur handyman.
I’ve seen the same thing happen in many IT projects. The people in the organization overestimate their own skills and are unable or unwilling to pay the cost of professional external assistance. Unfortunately, the outcome is often the same as for the DIY home projects above.
A recent example is the still-not-finished Cover Oregon healthcare website. IT World reports that Oregon decided to do the system integration themselves, using software and consultants from Oracle Corporation. They struggle and are blaming Oracle. Contrary to the usual commentary from large IT vendors, Oracle is pushing back strongly, saying “Cover Oregon lacked the skills, knowledge or ability to be successful as the systems integrator on an undertaking of this scope and complexity.”
You need a realistic picture of your skills before you start a major project to avoid DIY disasters. Contact me if you think you could benefit from an independent review of your organizational skill level vs. the task at hand.
Here is a way you might build a IT system: The users tell you what they want, and you build what they asked for. Sometimes you get it right, especially if you have good communication with end users and an iterative approach. Sometimes you get it wrong, especially if you have no communication with end users and a year-long waterfall project.
Here’s another way to build an IT system: You observe the users and figure out what they need.
Steve Jobs had it right when he famously said “A lot of times, people don’t know what they want until you show it to them.” For those of us without Steve’s almost infallible intuition about what people want, actually watching users will provide much more information and give you a much higher chance of building something that actually helps real users.
The U.S. Department of Defence has long been fighting a valiant rear-guard action in defense of Waterfall project methodologies. However, the times they are a-changing.
A colleague just pointed out the revolution hidden in section 804 of the U.S. National Defense Authorization Act for Fiscal Year 2010:
SEC. 804. IMPLEMENTATION OF NEW ACQUISITION PROCESS FOR INFORMATION TECHNOLOGY SYSTEMS. (a) NEW ACQUISITION PROCESS REQUIRED
The Secretary of Defense shall develop and implement a new acquisition process for information technology systems….
(2) be designed to include—
(A) early and continual involvement of the user;
(B) multiple, rapidly executed increments or releases of capability;
(C) early, successive prototyping to support an evolutionary approach; and
(D) a modular, open-systems approach.
That sounds a lot like agile to me. It will be interesting to see how this plays out in real life once U.S. government eventually starts working again.
Here in Denmark, we have had the opportunity to make the world a better place by purchase the services of the organization “Better Place”. Their business concept was to offer electric vehicles with interchangeable batteries and cover our small country with automatic battery replacement stations. If you needed to drive longer than the range of your battery, you would simply pull into a battery replacement station that looked like an automated car wash. A robot would remove the battery from under your car and replace it with a new one in less time than it takes to fill up at a gas station.
Sounds like a great idea, right?
Wrong. Just a few of the objections that immediately came into my mind when I first heard about the concept:
- If humanity can’t build a vending machine that reliably dispenses a soft drink, what is the chance that the battery changing robot won’t jam, carrying an 800-kilo battery?
- If I decide to visit family for Christmas (when everybody else is also driving), what are the chances that there will be a charged battery ready for me at the next changing station?
- I have to purchase a car that matches the battery pack (one model available); a car that is useless in case Better Place goes bankrupt.
They did go bankrupt last week after burning through about half a billion dollars.
The people behind this were clever people with experience from both automobile and energy sector, but they still fell prey to a case of “groupthink.” This happens when a group of people collectively reinforce their own ideas and reject evidence to the contrary.
Do you have someone from outside the organization help you reality check your great ideas before major investments?