As your team’s leader, you will be responsible for projects and for tasks within projects. You may also assign projects for your subordinates to manage.

Project management is a discipline all to itself. It increases the number of successful projects (i.e., projects that are on time and within budget) by using a disciplined, industry-standard framework for running projects.

A project has several characteristics that make it different from day-to-day operations. Operational tasks are recurring tasks that are required to keep the environment in good working order. A project, on the other hand, is a temporary undertaking with a specific defined goal.

The key word in that definition is goal. If the goal is not defined, approved, and published, the project is guaranteed never to succeed. Without a defined goal, a project will become a Christmas tree, where everyone who wants anything will hang their particular ornament. In the world of project management, this is known as scope creep.

The other key in the definition of a project is that it is temporary, with a well-defined beginning and end. Because we are working toward a concrete goal that goal will be accomplished, and the project will end.

When running a project, the overall goal has to be divided up into bite-sized tasks. These tasks are assigned to a team or an individual for completion. We also map out the dependency relationships between the tasks (i.e., which tasks are dependent on the outcome of a previous task). Understanding the dependency relationships between the tasks and the resources needed for each task is the key to drawing up budgets for the money and time needed for the project.

What makes a project different from a task is that a project requires resources from several different people or groups. Coordinating these requirements is what a project manager does.

This chapter discusses many tools that are at the disposal of a project manager. Keep in mind that these tools are only useful as far as they help to achieve project goals. You can spend all your time fiddling spreadsheets without having a positive impact on the project. Everything you do needs to move the project closer to completion.

Setting Expectations

A project’s size, usually known as its scope, has to be set as a defined, reasonable objective. A published scope, with measurable objectives, is the key to managing expectations from the people who depend on the project.

Project expectations are governed by the constraints of project management:

• Capability. The number and size of the deliverables in the project objective.
• Time. How long (in calendar time) it will take to complete the project scope.
• Cost. This includes both monetary costs as well as indirect costs (such as staff time or other resources).
• Quality. How reliable and robust the system is.

Part of defining a project’s scope is identifying which of the constraints is the highest priority for the project’s sponsor. You can’t have a project be cheap and fast and still have it be feature rich. There is a balancing point in there somewhere that meets the needs of the organization.

Project management is not quite that simple. Drawing up and agreeing to the project objectives is a process all by itself. We try to maximize the project’s usefulness by negotiating with the different stakeholders in the project.

Project Phases

Part of the nature of projects is that they have distinct phases. One common way of designating these phases is represented by Figure 4-1:

• Concept. This is the phase where an idea is crystallized with preliminary estimates and feasibility studies. This phase should include preliminary timelines and cost estimates based on an agreed project scope.
• Development. In this phase, the project plan is developed and improved. The task list should be detailed thoroughly, and a budgetary cost estimate should be approved.
• Implementation. In this phase, the project is executed according to the plan. Progress is measured and tracked, and stakeholders are kept in the loop.
• Closeout. Once the implementation work is completed, the customer needs to accept the work. Postmortem sessions and reports should also be completed in this phase.

Figure 4-1 is appropriate for many projects, but some projects are better suited to an iterative model. In an iterative model, the emphasis is on delivering chunks of functionality or prototypes on an accelerated schedule, then repeating the process until the business unit is satisfied with the results. Figure 4-2 diagrams an iterative model.

Iterative models are often timeboxed, meaning that the cycles have a defined length, usually only a few weeks.

There are several advantages to an iterative model:

• Progress is tangible and visible to the business unit.
• It provides a natural way to deal with evolving requirements as business needs change.
• Timeboxing provides a constant incentive to the development teams to produce.
• The most important functionality is usually delivered first. If the project runs out of time or resources, some business value will still have been provided before the project’s end.

There also are some disadvantages:

• The structure of an iterative cycle can be used to excuse a failure to plan or architect properly.
• Discipline is needed to close out a project rather than allowing it to cycle endlessly.

Regardless of the approach, one of the best predictors of project success is if an organization follows a consistent process for initiating, reviewing, and executing projects. Failed projects can be hugely expensive for the organization. Having concrete phases and gate procedures is part of having a robust project management process to focus resources on business priorities.

Scope Definition

The project has to be defined. This includes defining the size of the project, as well as what the success criteria will be. Usually, a business case is drafted to justify the project’s costs.

Part of defining the scope is identifying all the key stakeholders. The stakeholders must agree to the scope prior to beginning, and changes to the scope have to be accompanied with the resources to make those changes.

The initial scope of the project is defined and published in a document known as a project charter. The charter must be accepted by the key stakeholders; if a stakeholder is not on board that person or group may actively or inadvertently sabotage the project.

In many cases, it is best to finish the project with a limited scope, and then add features or functionality as part of a follow-up project. If a project manager does not control scope creep, the project is doomed to meander about and eventually fail when patience and resources are exhausted.

Business Case

A business case is exactly what it sounds like. It is a case made to management to secure the resources needed to pursue the project. A typical business case includes several elements:

• Business objective. What problem is being resolved by this project?
• Current situation. This may be presented in a SWOT format (Strengths, Weaknesses, Opportunities, and Threats).
• Options. Alternative ways of attacking the problem.
• Recommendation. Which one is preferred by the technical community? Why?
• Project requirements. What resources will be needed to accomplish the project?
• Financials. What is the preliminary budget? What is the estimated total impact of the project (costs and benefits)? The project manager should provide cost estimates for the expected lifetime of the project, not just the time to delivery. Budgeting is discussed further in Chapter 8.
• Estimated schedule. The schedule will be rough at this stage. Try to make it realistic. Base it on previous project experiences, if possible.
• Known risks. Include some proposed ways of dealing with these risks.

Organizations may have standard formats in which this information is expected to be presented, or methods that are used to estimate the financial impact. If you can look at a previous successful business case that may help format your business case the way that management likes to see it.

Project Charter

As its name suggests, the project charter is the document that kicks off a project. This document is a formal recognition of the project and its authority to call on the organization’s resources to execute the project. The charter provides managerial direction for the objectives and management of the project.

Project charters should include the following:

• Project name and authorization date.
• Project manager’s name and contact information.
• Schedule overview, based on the initial draft schedule.
• Budgetary guidance.
• High-level description of the project objectives.
• Summary of the approach planned for managing the project.
• List of roles and responsibilities.

Project charters may also contain additional comments or clarifications by stakeholders.

The charter is the founding document for the project. It is likely to be referenced repeatedly by those trying to affect the course of the project.

The level of detail in the charter is important. You don’t want it to have too little detail, or different stakeholders will read their own preferences into the charter and insist on their own interpretation. Too much detail ties your hands and prevents you from doing what you need to do to bring the project in. The appropriate level of detail is going to depend on the project and the nature of the relationships between the different stakeholder groups.

Scope Statement

It is common for two scope statements to be produced during the early part of a project. Frequently, a preliminary scope statement (a “vision statement” or “scope charter”) will be created from the project charter and circulated for discussion. A more detailed scope statement would be generated later to direct the project and to act as a control on scope creep.

The initial project charter is a very good place to start when developing the initial scope statement. The scope charter is likely to be high level, and is likely not to specify technical means required to achieve results.

There will be several scope statements circulated during the initial stages of the project. Each will become more detailed and will reflect the emerging consensus about what this project consists of.

There will always be pressure to expand the scope of a project. If the scope is allowed to grow too large, the project will lose focus and may never reach completion. There is a lot to be said for creating one project to create the base functionality and foundation for further growth. Additional features can be added as additional projects. Reducing the scope in this way increases the likelihood of success, and also cuts the time required to delivery meaningful functionality to the business.

When trying to decide what should be defined as base functionality, a good test is to look at the business impact of the different proposals. The key is to get significant business impact delivered quickly, in a way that will enable further enhancements to also be delivered efficiently.

Scope Management

If you don’t manage the scope, it will manage you. Every stakeholder has a distinct view of what the scope of the project should be. Once you have a preliminary scope statement in place, changes can only be permitted within the context of project change control.

The tools you have at your disposal to manage the scope are

• Planning process. This starts with deciding how the preliminary scope statement will be developed and evolve. Throughout the lifetime of the project, this planning process will have to be robust to define an achievable scope and filter proposed changes.
• Task management. As the scope develops, the task list or work breakdown structure (WBS) has to develop at the same time. If scope changes are not reflected and tracked in the WBS, project management will not focus on the correct issues.
• Verification and control. The scope change management process has to be robust, and project management has to be disciplined about enforcing its use. Stakeholders must agree to the downstream effects of project plan changes, including resource and schedule impacts of changes.

Each of these tools must be in place to manage a project’s scope properly. An accurate WBS is impossible without a solid scope statement, and a stable scope statement only exists if the planning and control processes are also solid.

You have a few tools at your disposal to manage the scope, but political pressure will always be brought to bear to implement changes to the scope. There are a few different techniques you can use to combat scope creep. These would be used in conjunction with your change control process:

• Cost. Put a dollar amount on the resources required to implement a change, and ask the requestor and CCB to identify the budget the costs should be charged to. Once it comes down to budgetary dollars, people start getting serious about which scope changes are actually necessary.
• Time. Put a time on the delay that the request will cause to the project timeline. When people have to take responsibility for delaying the overall project deliverables, people become more flexible about the changes they are demanding.
• Trade-offs. Ask which existing requirement should be dropped to free up the resources needed to execute the change. There are always limited resources, and the most important items should be done first. By pitting requirements against each other, you force a decision about which priorities should be addressed first.

Stakeholders

Early in the project, a project manager needs to identify the stakeholders and decision makers. For each of the stakeholder groups, escalation procedures must be identified to deal with the unexpected.

Stakeholder management can be like herding cats. Different teams have different priorities. One of the more difficult tasks a project manager has is to identify a reasonable path forward that addresses all the most important stakeholder concerns without blowing either the budget or the timeline.

For anything beyond a simple project, project managers should produce a separate analysis of the stakeholders in the project. This should include information about organization and contact information for different stakeholder communities. It also may contain information about concerns about different stakeholder communities. This analysis probably should not be part of the public project management plan because some of the information may be confidential. The stakeholder analysis may only be shared among people directly responsible for managing the project, so that the project managers can feel comfortable communicating personal information about the stakeholders, and how to adjust the project management methods to fit their needs.

Work Breakdown Structure

One of the key coordination tasks for a project manager is the definition of a task list (sometimes called a work breakdown structure or WBS). The task list needs to identify a brief description of the task, the person (or group) responsible for the task, the approximate amount of time required to execute it, and the dependency relationships between tasks.

Specifications and requirements are not included in a WBS. A WBS only includes tasks; specifications and requirements are tracked separately. Because the requirements may affect the time estimates for a task, it is important to have the implementers review both the requirements and the time estimates.

The WBS is created by breaking down the project deliverables into smaller and smaller chunks. Each of these should continue to be decomposed until they arrive at the level of a task that is assignable and schedulable. These tasks at the lowest level of a WBS are sometimes called work packages. The amount of effort represented by a work package will depend on the length of the project and how frequently updates are required.

Resource and dependency scheduling will usually be handled at the work package level, so that is the level where the project manager needs to provide tracking and accountability. If weekly updates are needed to keep a multimonth project on track, for example, a work package should include no more than 40 hours of effort.

There are a number of tools that can be used to track task lists and dependency relationships. Microsoft Project is the best known of the commercial tools. There are also free tools such as GanttProject (http://www.ganttproject.biz/download) that have similar functionality, and can even save files in MS Project format. Some project managers prefer old-fashioned spreadsheets, but those can become unwieldy once the project grows past a certain size.

Whichever tool is used, the most important basic analysis is done at the task level. If you don’t know what you want people to do, there is no way you are going to be able to estimate the resources you need to do it.

As you define the list of tasks, you will need to speak to the teams who will execute those tasks for estimates of the time they will need, the number of people they will need to commit, and the dependency relationships they have with other tasks. It is very common for one task to need to be split up into smaller tasks assigned to different groups.

Resource Estimates

Throughout the project, the project manager is responsible for tracking the resources needed to bring the project to completion. This includes the people needed as well as the cost in dollars, facilities, and material. A preliminary estimate is drawn up before the project is approved, but the project manager has to keep a handle on the resource estimates as they change over the course of the project.

The basic tool for making the resource estimates will be the task list. Most projects have a large number of similar tasks; as each task is completed, you need to see if timelines for other tasks will need to be adjusted.

The advantage of a project management tool (rather than a simple spreadsheet or document), is that it will automatically adjust timelines and estimates based on changes to tasks in the plan. It will also help us view critical path changes.

The critical path is the name given to the path of tasks that is keeping the overall project from being any shorter.

Each task can be viewed as being part of a tree of dependency relationships, both of tasks that must be completed before this one, and also the tasks that are waiting for this one.

The critical path is calculated by looking at the durations of tasks in a dependency tree, and selecting dependency tree with the longest time duration.

This particular path is the “critical” path because if some of its elements can be shortened, the overall project time line can be shortened. Or, if one of its tasks is delayed, that will cause a delay in the overall project.

One of the earliest indicators of a project in trouble is when the resource requirements start to spiral up. It is the project manager’s responsibility to track these requirements against what was approved for the project, and to alert project stakeholders if they start increasing in a way that puts the project in jeopardy.

As the WBS is completed, there will almost certainly be people who are assigned more tasks than they can possibly complete in the times assigned. When this happens, the project manager has a few tools that can be used:

• Identify tasks or parts of tasks that can be done ahead of time.
• Reschedule some tasks to different parts of the project plan, so that the person can focus on the more critical tasks first.
• Find ways to re-assign some of the work to other people, perhaps by bringing in temporary help.

It is a myth that more people means a faster project completion. There is overhead associated with managing new people and bringing them up to speed. Even when they are up to speed, there is additional communications overhead for each additional person.

Here are a few suggestions for improving the quality of your schedule estimates: How accurate should the task estimates be? Are you looking for a guess? A good estimate? A thorough analysis? You will want to focus more attention on tasks that are on the critical path or that are part of a lot of dependency chains. When you request an estimate from an implementation team member, you can ask for accuracy in terms of a confidence level. (Are you 50% sure? 80%? 90%?) Treat these numbers as a way to communicate expectations to team members, but take those numbers with a grain of salt. (Don’t just use them for scheduling estimates because research shows that people routinely overestimate confidence levels.)

• Don’t ask for precise estimates of less important tasks. If you chew up all your team’s time making really good estimates, you will have less time to actually execute the project.
• Trust the experts. You can probably pressure the programmer to give you a smaller time estimate, but that doesn’t mean that the work will actually take less time.
• Provide accurate requirements. You can analyze garbage to within an inch of its life, but you will still get garbage output.
• Use previous project work as a baseline wherever possible. Just understand where the information is comparable, and where it is not.

Obtaining Requirements

Requirements can come out of interviews or workshop sessions. Sometimes requirements can be gathered by directly observing business processes. Gathering requirements is a skill that is developed over time. Professionals who gather business requirements for implementation are frequently known as business systems analysts.

There are several techniques that can be used to identify and nail down requirements:

• Mock-up. A mock-up is a nonworking model of a project component, usually used to demonstrate user interface functionality.
• Prototyping. A prototype is a working model of a component of the overall system. This method is especially useful for getting buy-in to interface requirements, because the input can be restricted or output canned to reflect look-and-feel types of operation. As components become more developed, they can be placed in a test harness to see how they would integrate into the whole.
• Use cases. Use-case modeling is a technique for identifying the steps that would happen as a system handles a typical operational case. This is less mechanistic than the way that a lot of techies look at how the system should operate, but use cases are accessible to most stakeholders, and they still provide a useful level of detail to the technical staff.
• Joint application design (JAD). This is a method that involves intense, structured workshops including all the stakeholders to try to bring out all the requirements. JAD brings the user community representatives into the requirements process in a focused way, which helps to increase their involvement and buy-in.

Beyond gathering requirements, you also need to get a feeling for how important each requirement is. Are they based on wants or needs? As the project progresses, there will be times you need to adjust the scope of the project, and it is best to know which parts of the scope have some flexibility in them.

Use cases, in particular, are a really useful way to gather C-level requirements at a useful level of detail. The information in a use case should include:

• Use case ID: Unique identifying number, preferably mapping to a C-level requirement.
• Summary: Verbal description of the use case.
• Rationale: Why the use case is needed.
• Actors: Groups of people or external systems that interact with this use case.
• Initial state: What needs to be in place at the beginning of the use case.
• Actions: The course of events in the use case.
• Alternate paths: Conditions where a similar, but not identical, course of actions would take place. (This allows us to collapse several similar, related use cases into one.)
• Final state: The status at the end of the use case.

These can be diagrammed in UML format (see Chapter 13), or they can be written out verbally, as in Example 4-1.

It also may be useful to use a spreadsheet or web form to gather the use case information in verbal format. Frequently, it is easiest to set up a spreadsheet template for the use cases, and to use the UML diagrams as ways to elicit requirements in workshops or to distribute them between the development and customer communities.

One way to find requirements that need to be clarified is to go back to the schedule estimates. Ask the implementation team which questions need to be answered for them to be able to provide a more accurate estimate. Sometimes the answers you get back will point at a major requirement that really needs to be nailed down.

Chapter 13 includes information on some tools that can be used to identify and communicate requirements.