Planning, Estimating and Managing Government Software Projects

Academic papers in computer science and systems engineering as well as newspaper exposés frequently cite horrific examples of cost overruns on software projects. When I see a headline like, “GAO Highlights DoD Cost Overruns” I shrug and say to myself, “here we go again.” What got me going down this thought path today was a recent headline in our local, “Austin Business Journal” titled State lacks sufficient IT planning.

What followed in the article – sorry the full article requires a subscription – chronicles 48 technology projects undertaken by the State of Texas, of which 32 were late and/or over budget. You can read the report, “2010 Quality Assurance Team Annual Report” in its entirety, if you are so inclined. The article suggests that the blame for recurrent failures falls on the “state employees tasked with planning and budgeting new technology projects.” The implication being that if the state employees managing the projects just knew how to estimate software development cost and schedule, then the projects would successfully complete on time and within budget.

In my opinion, it is not that simple.

Software Cost Estimating Theory
Back in December 2010, I talked about Estimating Project Costs. In theory, a project manager uses customer requirements, resource availability and required milestones to construct a realistic project schedule and budget. In complex projects, components may be estimated separately and then the estimates are combined or rolled-up with integration estimates to produce cost and schedule for the total project. Sophisticated cost estimating tools help project managers construct a cost and schedule using parametric models and lessons learned from previous, similar projects.

Software Cost Estimating Reality
First, let me say that no one wants to know how much it will cost to get a software solution to meet their needs because the number will be too high. Senior management wants a software cost and schedule that allows them to win a competition based on lowest bidder. Government agencies want a solution that fits within the budget that was already proposed and approved before the RFP was announced.

Getting from point A to point B often involves a complex dance using multiple contractors, combinations of off-the-shelf and developed software and workers located anywhere around the world working for small or medium sized companies or as individual contractors. The set of vendors working together comprise the “project team” each of whom was pressured to commit to a cost and schedule that meets the target established by the customer.

 I live in a large state with a state government budget that rivals many countries. To meet budget shortfalls, most states – including mine — have gone to a state run outsourcing model that encourages independent contractors and staffing firms to deliver “lowest cost.” What is happening is that they are not getting the right skill set and there is no synergy or “team” concept in these IT programs. Instead of utilizing two or three firms, who specialize in a particular area, they are putting 10 to 20 independent contractors together and saying – here is the schedule, make it happen.

This situation is a project manager’s nightmare. I hate to say I see the same trend in corporations…. They have stopped using small, expert firms and have gone to a staffing model that brings in independent contractors to work individual positions and tasks. I am only glad I am not in charge of one of those projects! 

I would love to say that I have THE SOLUTION. However, I don’t. I applaud government agencies and companies that accept “Best Value” rather than lowest bid – that is a start. I would like to see professional support for government agencies in creating realistic RFPs for software procurements. In addition, I think that a procurement model that involves selecting a trusted contract manager or contractor and then incrementally creating requirements and development cycles, rather than all or nothing development, has merit. Then I would like to see teams made up of the right professionals – especially Project Managers. We have to start acknowledging that not all people are good at everything and a good team is not a collection of random consultants.

Your thoughts, experiences and suggestions are encouraged.

PMBOK – The Case for Change Management

Early in my career, when I was an individual contributor on projects, I viewed meetings – including change control meetings – as an “interruption of” real work. Let me be clear, I WAS WRONG. As I moved into management of progressively larger projects, the need for a formalized way to deal with and document change requests became evident. Moreover, I became the one calling those meetings!

Is change after requirements are agreed upon inevitable?
Yes. Give me a user interface and I will find you several users who want changes made. No matter how conscientiously you gather user requirements during the early phases of a project; changes will be requested once users get their hands on the software during alpha or beta testing. I love that famous quote from Benjamin Franklin where he said, “In this world nothing can be said to be certain, except death and taxes.” I have a saying that I modified from Franklin’s – “There are only three things in life that are certain: death, taxes, and change.”

Partially this is human nature. A user envisioning a system that exists only on paper does not realize they will want to change font colors or have their spelling checked. New software has bugs that show up only during alpha and beta testing, when clever users finally get their hands on the software. Alternatively, the environment in which the software will operate changes, the customer adds data sources or new user groups.

As project manager, operations manager, or even VP, you must consider each change request in terms of its impact on cost, schedule, planned infrastructure, integration and input/output/processing modules. Now, just because a change is requested, does not mean you can or have to make the change, but you must consider it and document that consideration and the reasons the change request is rejected.

Components of an Effective Change Management Process
The PMBOK in sections 4.5 and 5.5 sees change management as part of an over-all integration of best practice processes that includes change requests, approval or rejection processes and management that includes deliverables organizational process assets, project documents and the project management plan. Change requests can include corrective action, preventive action and defect repairs.

A Change Control Board (CCB) reviews all requests and approves, delays or rejects them. The CCB should include key project staff, representatives of user groups and customers. It may also include software QA representatives, consultants or someone from the PMO.

All change requests should be identified by unique number and include information on the problem or desired change. A formal system to track change requests status, document costs and benefits, and provide feedback to stakeholders should be in place. The entire proceeding of the CCB meetings, the change requests and outcome actions become part of the project record.

Some Good News
Many changes you are asked to make improve the quality and functionality of your software. Useful enhancements that cannot readily be fit into schedules and budgets can form the basis for future contracts. The effort and documentation of the CCB protects your company if later problems arise with the customer’s satisfaction and payment.

Best Practice Tip
Not every project or organization is going to need the same type of change management or level or rigor.  The PMBOK outlines what functions and processes make up controlling scope and managing change – but not how to apply it to your specific needs.  If you are implementing a new project or establishing your organization’s change process and methodology, then get an experienced and trained PM or consultant to assist in applying this critical process area to your project or group.  A few well spent hours by a seasoned PM will pay off in the long run for your success in managing change.

Resources for More Information:
Project Smart; Using Change Management and Change Control Within a Project; Dave Litten; 2009

 Software Quality Assurance Organization: Software Quality Assurance within the CMMi Framework

The Ideal PM Tool set

PM Hut; Implementing Change Control

The Lazy Project Manager's Blog

The Home of Productive Laziness Thoughts

Thoughts, experience, tips and tricks on issues affecting managers and project management

A Girl's Guide to Project Management

Project Management musings for one and all

LeadingAnswers: Leadership and Agile Project Management Blog

Thoughts, experience, tips and tricks on issues affecting managers and project management

Project Management Hut

Thoughts, experience, tips and tricks on issues affecting managers and project management

Herding Cats

Thoughts, experience, tips and tricks on issues affecting managers and project management


Pushing the Edges Out ...


Just another site