You might remember a few months ago I wrote about Tech Stat, the series of Program Management Review meetings on several projects, one of which I am tangentially involved with. Well, 26 Projects have been officially put under the microscope. The project I consult on is on the list.
In addition to this though, Mr. Kundra, the OMB CIO, came to the Department for a Listening Session. It was clear that he had already been to several agencies already, including Commerce and the Department of Justice. I must admit that I was surprised by the informal nature of the session. First, instead of using the standard government 'panel discussion' format he had us re-arrange our chairs into 2 concentric circles so that everyone could see and share. Then there were some brief remarks by the Department's CIO followed by some remarks by Mr. Kundra, and then it was kind of a free-for-all.
There was a person taking notes on the themes that were discussed. There was one funny moment. Someone asked who would really tell OMB the truth about a project that was failing, I instinctively raised my hand and then realized too late that I would be the only person in the room. Since I was on the side, I didn't think anyone would notice. Wups, the note-taker totally caught me and pointed out later that I was the only person in the room who did that.
I took a couple notes about some items that are worth discussion. First, Mr. Kundra quoted that the rate of IT project failure from the 80's through the 2000's has increased. I think I would like to challenge this idea a little bit. I don't think the rate of failure has actually increased. I think the reporting of failures has increased. I think that before Clinger-Cohen the opportunity to obscure IT project failures was significantly better than it is today. As such, we have significantly better visibility into failures than we did before. I will grant you that we are working on several orders of magnitude more IT projects than we were 20 years ago, and the actual numbers of failed projects is bound to be larger, but I submit that it is likely that the percentage of failures is very likely to be less than the 80's and before. For sure that failure rate was better in 2009 than in the mid 90's, the first year of the Chaos Report (from the Standish Group). Regardless, my point here, is one of reporting, that we think there is more failures because we are more effectively reporting the failures.
Next, he used a great metaphor, he said that the purpose of Tech Stat is to "shine the light" on troubled projects. That is a really good metaphor. First, when you shine the light, you let the project know that external entities are watching, like a spotlight in an interrogation. But second, when I think of this, I think also think of a lighthouse that let's sailors know where the rocks are on a rough sea.
Finally, anyone who knows me knows that I can't keep my mouth shut. The idea that I floated, and I think it had some traction with the group was in designing the solution too early in the process. I thought about this over the weekend, and I think that I have a metaphor of my own for illustrating the issue:
We need an IT solution, let's just call it "The Box". The Box promises to do great things for us, so there is a lot of momentum to go it. But The Box is an expensive proposition, and even though we expect it to transform the business, we have to line up all the ducks to embark on the project. Thus we develop our OMB 300. Here is the first problem. The OMB 300 needs to be developed (they say 2, but it is actually) 3 years before we can begin the project so that it can be included in the funding cycle. Not only that, but we have to really design the box to create the OMB 300.
That's the problem. My project to create The Box, includes both requirements and design work. But 3 years before I start I am forced to design the solution? How can that make sense?
There are tons of people who evangelize Agile development. I've even written about it a couple times (one | two). But the problem is that the government hasn't learned how to balance the government's need to know what we're buying from both a capital planning and acquisition perspective with being Agile to meet business needs. So I go ahead and I develop the OMB 300 Business Case for The Box. I get approval and then I go ahead and develop my Acquisition Plan, work statement etc. for buy a system that looks like The Box.
Three years after the business community was so wound up to transform the business with The Box, we actually get started. The fallacy is that the requirements and design processes are complete. They can't be because we are limited in the scope of our solutions to what was written in the OMB 300 and what was written in the work statement. So rather than survey the entire field of opportunities to meet the need posed by The Box, we are limited to what we identified before any in-depth analysis was performed.
So now, The Box, the project that was intended to be this transformative project for the business, is now a box that confines our thinking and limits the range of solutions that we can consider. Please leave out-of-the box thinking at home, because we are building The Box, like it or not.
But it is really hard to get all these ducks in a row, and it seemed like a really good idea 3 years ago, so we should probably go for it. Never mind the fact that the leadership has changed and that the priorities for the business have changed. Build The Box.
So we embark on the project, and it is a big project. Let's say that it takes 3 years to build and deploy The Box. We get all the way to User Acceptance Testing and the business reviews The Box and they say, "This doesn't meet our needs." And I say, "How can that be? I built exactly what you told me. Here it is." I pull out the OMB 300 business case to show the business leader.
The problem is that in the most likely scenario, 6 years have passed from when the business had all that momentum to do something, and the point at which The Box was delivered.
Why can't we buy more things in bulk? Wouldn't it be cheaper if, when my wife and I have a child, we could go out to the store and buy all the milk to satisfy that child until he was 10? Or cereal? It seems like I buy a gallon or two of milk and a box of cereal every week. Each of these incremental purchases would be far less costly if I could really buy in bulk. The reason we don't make those ginormous purchases is because those staples, milk and cereal have an expiration date. They are no longer good after a specific period of time.
But we think that requirements act differently. We think that once we identify the requirement, in this case, to build The Box, that we can go about our business, build the box and deliver it and it will be considered just as valuable on the 2,190th day (six years) as it would have been on the 365th day.
Any Project Manager's ability, heck any person's ability to see beyond the horizon of 1 year is not very good. Because of this, we can make strategic plans that cover swaths of time, but we don't make tactical plans with that kind of time horizon. We make tactical decisions in one-year increments. Part of the reason for this is because requirements have a Freshness Factor.
A requirement is a requirement under very specific conditions. For example, the widget goes from A to B to C when we talk about designing The Box. But in the intervening 6 years, we have realigned the organization (probably twice), and B doesn't exist any more. So if you deliver The Box with the A -> B -> C routine, that won't work anymore and I'll need you to fix it.
This will cause a deviation in the cost and schedule of the project, and will, by the Standish Groups definition be labeled as a "Troubled Project" since it has variances in scope, time AND cost.
What's the solution to this dilemma? My solution is to not describe The Box at all. Think about it, the work that we will be paying for, the reason for the OMB 300 Business Case is to acquire services that will help us to build The Box, as in the solution. In the OMB 300 or Exhibit 53, and on the work statements we need to not describe the final solution. Any language that decribes The Box will necessarily limit the thinking when it comes to requirements and design to meet the business need. Instead of describing the product, describe the process. I've written about this before.
Next, know that the requirement for the business need has a freshness factor. If you can deliver it timely then you will satisfy the business completely. If you deliver it later than timely then the level of satisfaction will be less than complete. The hard work is to identify the specific metric for Timely. Remember, I am not kidding about the ability to see beyond a 1-year horizon. My recommendation is that you deliver functionality into the production environment in 1 year increments. You can still do big things. In the example above, The Box took 3 years to develop. OK, break The Box into parts or modules and deliver them over that timeframe. That is what a PM should be good at, chunking the project.
Consider the OMB 300 to be the strategic plan, but then consider that each year will have a tactical plan, or an action plan. You can't begin writing the follow-up action plan until you are 50-75% done with the current one. This will help to alleviate McConnell's Cone of Uncertainty, which, for Mr. Kundra, was one of the things he said he would take away from the discussion.