Preventing Project Failure

My team is starting to get a lot more work. As a group dedicated to SDLC discipline we have bought in good process that makes our clients feel secure and we are proving that process works through encouraging consensus, through not moving forward until we have clear requirements, through honestly and actively managing risks and ensuring quality through system architecture and testing, (I know…yadda yadda yadda).

So ..last week we got a new client. I found out about the client on Tuesday via phone directive from a senior-control-the-purse-strings exec. It’s all good because the work falls under our program mission. So Wednesday, we met for the first time with the client. Thursday I wrote up the charter and held a scope meeting teleconference with the POCs. By Thursday evening the draft charter was done and I knew:

What were the key points of process pain

What the overall doctrine and mission was driving the emergent need for a change

What the application was supposed to do

Who the stakeholders were both internally, and externally and

High level risks

And I stood back from my creation, the way a mad scientist steps back from the machine he has worked on for days, and realized…..dang! That was quick!

Talking to the Senior BA on the team we both realized that perhaps we had hit on a formula. We’ve been in the DoD environment for almost a year and I know that doesn’t make us pros in Dod IT. But what we do bring is experience in corporate America CMMI level 3 and 4 IT shops. And that experience, and subsequent application of laser focused methodology we absorbed in those environments, means that we have established repeatable processes from which we are starting to see patterns. For initial project scoping, the patterns are lending themselves to some potential themes which I thought I would share with you.

DoD IT Theme 1: The Two Reasons for Everything Office automation applications are meant to do one of two things:

Get information faster

Reduce the time it takes to get things done

To be successful, we focus on finding out what that needed information is, who owns it and how we’re going to get it and manage it. And if the app is envisioned to reduce time, then we find out what bottlenecks exist and how the app is supposed to fix the bottlenecks. The two reasons imply that there is pain the process somewhere, and if there is no pain, then there may not be enough support for the app if for example, another point of pain becomes a higher priority.

DoD IT Theme 2: The Doctrine is the Key Every organization in the DoD has an overriding doctrine that determines the mission. You need to understand the doctrine to understand how the organization you’re working for fits into the whole structure. And you need to understand the fit to know:

The true reason for the existence of group you serve and what they are supposed to accomplish

Additional stakeholders you need to include in your project planning

Additional data silos you may need to peek into or get data from

DoD IT Theme 3: Vetting Takes Time Finally, there is the stakeholder formula – how long it’s going to take to get everybody to agree. Basically, the Pentagon is a huge vetting organization. Anything you do will have to go though a lot of people for approval. The more external organizations you have to connect to, the more risk is automatically assumed and the longer the application is going to take to get done. So I think it goes like this; for every additional outside stakeholder group you have to connect with, add planning time. Your first group adds on at least one month. Additional groups add on additional 2 weeks.

# of Groups and approximate Vetting Times

1 group = 1 month

2 groups = 1.5 months

3 groups = 2 months

4 groups =  2.5 month

5 groups =  3 month

6 groups =  3.5 months

Making it usable Here’s how these three themes worked for me:

Theme 1: On this project, during initial scoping, I probed to see if either the new application is envisioned to get information faster and/or reduce the time it takes to get things done. This line of inquiry was fruitful in getting to the true need, which is what the business case hinges on. And the fixing of this problem ‘thing’ will bring capability to the organization that didn’t exist before.

Theme 2: I asked for the doctrine supporting the mission of the organization. I then found the doctrine online, studied it and got up to speed fairly quickly on additional stakeholders and silos. This got added to the Charter as the overriding guidance to follow and was confirmed later by the POCs.

Theme 3: This application will take a considerable amount of information consolidation with about 3 different organizations. This has become a risk to mitigate that we’ll discuss in our risk mitigation session next week.

What could have happened Had I not been aware of these themes here’s what would have happened:

Missing Theme 1: I would not have realized that we were replacing a manual process that caused a lot of misaligned information. This fact didn’t come out until I asked specifically about the reduction of time question. And the implication is that we would not have studied this existing process to ensure we ported it over correctly to the app. It would have been lost until the last minute when someone would have said ‘hey – what about Form A, B and C – we need to automate those too.’

Missing Theme 2: I would have a conception of the envisioned application that was wrong. By studying the doctrine I realized that there were two aspects of the mission that needed to be addressed to be successful, not one. We would have built for one thing only, and the other would rear its head probably super close to deployment, well after the app was built.

Missing Theme 3: I would have built a schedule around just this organization only to have it skewered by outside groups who would get miffed by not being included in the planning.

You know what they say, an Ounce of Prevention is worth a Pound of cure.

• • Comments [0]
  • Tags [DoD, Project Scope]
  • Categories [Controlling Scope, Real Life]