December 23, 2010 — Bruce McGraw Establishing a project budget can be as simple as calculating what it will cost to perform each task in the work breakdown structure and adding them to get a total budget. However, as any project manager who has created a project budget knows, creating a project budget is rarely simple or straightforward (and usually not totally in your control!). The complicating factors include clients who want as much functionality as possible for the lowest cost, business development and sales staff who wants to win contracts, and senior managers who want to maximize profits. In addition, everyone wants the product to work well and be easy to use. The person in the middle of this vested-interest conflict is the project manager. And for those certified PMPs, there is a whole section in the PMBOK® that talks about this topic. Planning in chapter 3 talks about estimating costs and then budget as a part of the planning process and then chapter 7 “Project Cost Management” discusses the techniques and best practices for preparing budgets and managing the costs. Just because creating an acceptable project budget is not simple does not mean you will not have to do it. So, how can a project manager protect the hoped for success of the project and manage risks by not agreeing to do more than can be done? Not the Dilbert way – of course. Checking out PMBOK, Chapter 7, they suggest beginning with project scope, which may require the addition of design detail to create defendable cost numbers. You also need the project schedule and information on staff availability. Once you know what needs to be done, how quickly and by whom, cost estimating can begin. PMBOK lists several cost estimating methods that may be done alone or in complementary fashion. Expert judgment – your experience on similar tasks and projects, input from consultants Analogous estimating – other similar organization projects cost history data Parametric estimating – Parametric Cost Estimating Handbook from NASA offers guidance, though somewhat dated. COCOMO II is used in traditional waterfall style software development. According to S. Chandrasekaran from St.Joseph’s College of Engineering, Agile software development requires a different cost estimating model which he describes in his paper, “Multi-criteria Approach for Agile Software Cost Estimating Model,” which can be found with other cost estimating articles at 2Dix. Bottom up Three point estimating – most likely, optimistic, pessimistic Reserve analysis – with a contingency fund to cover uncertainty in estimates Cost of quality – add in My advice to you is “back up your estimates with data”. Be prepared to justify costs and explain risks – in non-technical terms — of making too optimistic assumptions. Try to achieve reduction in scope commensurate with lowered budgets. Do not feel too badly if you lose some of the cost estimating battles. The real key is to document your assumptions (like there are 7 modules to design, or we will perform 2 week long tests). What has been your experience with cost estimating software projects in the real world? Do you pad your estimates knowing you may have to settle for less? Or do you just add some contingency to duration and costs?

August 11, 2011 — Bruce McGraw

OK, it has been a while since I talked about the PMBOK and I wanted to continue a series of posts on PMI PMBOK areas (started with “What is the PMBOK all about”.  This week we look at one of the critical areas that many PMs shortchange in managing projects – planning

“No battle plan survives contact with the enemy” is a bit of wisdom about the world alternately attributed to Helmuth von Moltke the Elder, Erwin Rommel, Carl von Clausewitz, Colin Powell and Murphy’s Laws of War. Yet, military leaders continue to develop plans for every imaginable contingency. If plans are destined to fail in the real world, why should we as project managers bother with planning?

Plans rarely fail entirely. Rather, details of a plan require changes as factors outside the control of the PM require responses that deviate from the original plan. However, a project plan provides a roadmap of key destinations (milestones) and a timeline to reach those locations, even when detours become necessary.

Of course, the PMBOK addresses project planning in detail beginning in Section 3.4. It suggests that a project plan encompass:

• Scope
• Activities
• Resources
• Schedule
• Quality assurance
• Risk analysis

In the discussion, PMBOK acknowledges that, “as more information is gathered and understood – which is their way of saying contact with the enemy — additional planning may be required.”

Types of Plans

Creating a project plan is not a trivial exercise. The project manager needs to spend time gathering requirements from a variety of stakeholders and working closely with key technical staff to identify strategies and risks. For large or complex projects, creating even the initial plan may take several weeks. However, not all projects are “created equal” and some may not justify this amount of effort. Sometimes a project plan can be created on the back of an envelope (and, of course, captured in more detail during documentation – MS Excel is probably the most popular way many of you do this.)

• Exploratory Plans: these often begin with a conversation and some, “what ifs.” A creative developer has an idea for a potentially useful software tool or an alternate approach to solving a vexing problem. What makes these thought exercises a project that requires planning is the need for resources. It is one thing to have an idea. However to try it out and test its utility, someone has to approve the objective and the allocation of hardware and human resources. Even exploratory projects need a statement of the problem, a sequence of steps, a schedule and a method to evaluate outcomes.
• Agile Development Plans: I discussed Agile Development methodology in “Project Management and the Agility Factor” as a style of project development that focuses on short iterations of feature development. Kent McDonald, writing for ProjectConnections, suggests that a Project Plan for Agile Development would only cover a period of two to four weeks. “During those iterations, all of the necessary work to take features from an idea to a working product is completed …” Each iteration begins with a feature-based plan that includes detailed tasks, schedule and deliverables.
• Traditional Waterfall Plans: When waterfall development method is used on a project, the project management plan covers the life cycle of the project in discrete steps beginning with requirements analysis followed by design, implementation, test and maintenance. Because plans developed for waterfall method projects may cover months or even years of activity, these plans are more likely to require re-planning driven by external events.

Characteristics of a Good Project Management Plan

Here are a few tips to help you make a better project plan:

• Cover all the bases listed in PMBOK
• Clearly defines the scope of the project
• Show dependencies between tasks as part of risk management
• Comprehend resource loading and realistic levels of effort
• Reflect awareness of project risks and allow time to understand and mitigate them
• Accompany the plan with a communication plan that explains goals, tasks, schedule and performance information with key stakeholders
• Include qualitative measurement of deliverables tied to project requirements (Focused on outcomes and not just widgets)
• Help developers, team leaders and users understand the project and their role in its success
• Make sure the plan is sized appropriate to the scope and size of the project (“Not too big, not too small but just right”)