I often say that it would be easier to develop a project manager crystal ball, or a time machine so that we could peer into the future and account for all those events. But since these innovations aren’t imminent, let’s attack the problem from the other direction by shortening the time horizon. A project manager may not be as accurate when it comes to planning for 78 weeks, but I bet he or she can plan for four weeks. If we shorten that cone of uncertainty to go from initial concept to software complete in four weeks, then I think we can get to numbers that will make more sense. You can still accomplish the same big things, but instead of engaging one single project to do it, you are going to have 19 four-week projects. Instead of spending a million dollars, you are going to fund each of those 19 projects with $51,000.
Don’t misunderstand, you will still need to account for risk throughout the projects. Some will take a little longer, some a little shorter, some more expensive and some less, but the key difference is that at the conclusion of each of those 19 projects, you have something to show for the effort and investment and at the end of all 19 you have something really significant that you effectively planned and budgeted. You have working software. This is different from the technical earned value that you accrue in an ANSI/EIA 748 situation. If people start talking about ANSI standards for IT projects, take your foot and throw it at them. You are not aiming to earn value in the same way that they are. You are trying to earn value the really old-fashioned way, by letting the customer experience the working software on the screen.
Momentum
This is an important concept because of the momentum of software development projects. Buckle your seat belts because I’m about to talk about feelings. How do you think most people feel about a project at the beginning of the project? I would argue that the kickoff meeting for a brand new development project is when everyone is at their best. Motivation is high, everyone is in good spirits and we’re all going to kick so much ass. Then as you get into the project, especially in a waterfail project, stuff drags on, and people start to lose that momentum. People only pick up momentum again when they start to get into User Acceptance Testing prior to launch. Ryan Nelson and Karen Jansen at the University of Virginia studied this. The image below is an example of a project that launched, didn’t go so well, and had a shadow project behind it to fix stuff that was wrong from the initial release.
I like to look at the “client” curve and the “vendor” curve separately. The client curve is exactly the way I feel at the beginning of a project. I feel like it is going to be great and we worked on requirements, and I felt like the vendor got it and understood what I was trying to convey. But then they would go off on that back room and develop and it was like a chef who wouldn’t allow you to go into the kitchen. Too frequently we would come back for testing in the final phase, and we would be like, “what the frick is this?” only we wouldn’t use the word “frick.” That is depicted by the pre-launch trough of disillusionment, to steal a phrase from Gartner. The big problem here is that if you lose confidence in a vendor, you may never get it back. So, for you vendors out there, pay attention to the momentum from the government client.
If you look at the vendor curve in this graph, that tells a different story. At the beginning they are like, “What have we gotten ourselves into,” but then, after requirements they pick up momentum because they think they got it, and it is only after they see the reaction from the client that they are like, “oh, we didn’t get it.” But then their momentum picks up again in the shadow project because they think they “got it right this time.” But their hopes are dashed when the client doesn’t perk up.
My point here is, think about momentum in a 78-week project versus a four-week project. Maybe you lose a little momentum at the end of each four-week increment or sprint, but you will be avoiding the big crash that you realized in the waterfail projects. The graph below is what we should be aiming for in an agile environment.
