Project Management
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.
Note Project management is a much bigger topic than we can cover in one chapter. Please check into some of the references at the end of the chapter for a more complete view.
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:
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 ROLES
Here are several roles that are important when setting up a project:
Project Champion. This person is someone high in the organization who is a key proponent of the project. Strong commitment to a project by a champion is a good predictor of project success. A champion can help corral needed approvals, resources, and attention to move a project along.
Project Sponsor. This person provides the leadership and political juice to move the project forward. The project sponsor will provide the funding and have the ultimate say on the direction of the project.
Project Manager. This person coordinates the work involved in the project, and makes sure that the project milestones are being achieved within time and budget constraints.
Project Team. Project tasks are assigned to different members of the project team.
Stakeholders. Stakeholders are the people who have an interest in the project. This includes customers and implementers of the project, as well as those funding it. The stakeholder community will have different interests. One of the challenges a project manager faces is balancing the different demands from the stakeholder community.
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:
Figure 4-1. Project phases
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.
Figure 4-2. 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:
There also are some disadvantages:
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.
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.
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:
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.
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 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.
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.
STRUCTURING A SCOPE STATEMENT
Here is a common way to structure a scope statement. Depending on the complexity of the project, the “Requirements,” “Product Deliverables,” and “Success Criteria” sections may be split out into separate detailed documents. In that case, include a summary in the scope statement and a pointer to each detailed document.
Project Title: This is a unique name for the project. It is used to track project progress and costs in reports to management.
Document Version Number: This document will evolve over time. To see which version is current, a version number should be assigned to each version and incremented as the document is updated.
Date: The date the document was prepared by the project management team.
Prepared By: The name and contact information (including phone number and email address) for the project managers who prepared the document.
Project Justification: A brief one-paragraph description of why the project is necessary, including:
Requirements: A numbered list of the requirements for the project. The initial list of requirements will probably be very general. The requirement specifications will become more detailed over the course of the project. Requirement numbers should not be re-assigned if requirements are retired; a requirement should keep the same reference number throughout the course of the project. If a requirement is removed, line it out rather than re-assigning its reference number.
Deliverables: This will be a list of what the project manager is committing to deliver as part of the project.
Success Criteria: Project completion within budget and on schedule are typical examples of success criteria. Special points of emphasis should be included here, such as specific milestones or deadlines that have a significant business impact.
Deliverables Postponed: When stakeholders agree to postpone a feature for a later version, keep track of the agreement. Otherwise, you will find yourself having the same discussion over and over, reminding people that the feature was postponed.
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
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.
Note As part of the scope verification process, the completed project scope statement must be accepted by the stakeholders. Stakeholders need to agree to a clear change control process, including a strong change control board (CCB).
If you don’t instill this discipline up front, you will spend a lot of time regretting it once you get into the meat of the project.
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:
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.
Stakeholders will need to agree to team contracts. Depending on what is required from the stakeholder, the contract may include the following items:
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.
A rule of thumb is that any project can be decomposed into 10–20 items. Each of these can be decomposed further until we get to a level where each item is a work package. This is an example of a “top-down” method for producing a work breakdown structure.
There are a few different approaches that project managers use to develop a WBS. Some of these include:
Figure 4-3. Mind map example of a simple project
Of necessity, several of the tasks will have descriptions that are telegraphic, if not vague. A WBS dictionary should be included to define what each task means. This is usually a document that is distributed with or linked from the WBS. The WBS dictionary may include links to the requirements.
WBS CONSTRUCTION
Here are a few principles to follow when constructing a WBS:
Uniqueness. Each work package appears only one place in a WBS.
Dependencies can be defined in the tool used to create the WBS. (This is much easier in a specialized tool such as Microsoft Project or GanttProject, as opposed to a spreadsheet.)
Nesting. Each WBS item consists exactly of the work packages below it in the WBS hierarchy. Dependencies should be tracked as dependencies, not by considering a work package to belong to two different hierarchies.
Accountability. Each WBS item belongs to a named person, even if some of the work packages are done by other people.
Consistency. The WBS needs to be consistent with how the work will actually be performed. The structure must be defined by reality, not aesthetics.
Buy-in. The project team has to be involved in constructing the WBS, to develop buy-in and ensure consistency.
Clarity. WBS items must be understandable, which probably means a definition in the WBS dictionary.
Flexibility. The WBS must be constructed in such a way that updates are doable. No matter how much planning and discussion is done up front, there will be changes. It is easier to implement these changes in a project management tool as opposed to a spreadsheet.
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:
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.
Brooks’ Corollary There is an incremental person who, when added to a project, slows down the project delivery.
Estimation is not an easy skill to learn. When you find that your estimates are significantly off, you will need to find out what you are missing.
Many technical people dramatically underestimate the amount of time required for planning tasks such as sketching designs or attending planning meetings. Try to identify the types of things that are being missed in the estimates by asking clarifying questions. Once you identify someone’s blind spots, help them to account for them in their estimates. It may be as mechanical as giving them a template including lines for the frequently overlooked items.
For each task in the WBS, you need three numbers. You will need a best case, worst case, and most likely you will need to estimate for the amount of time needed for the task. These numbers will be used to perform scheduling estimates.
PERT analyses are a common way to provide schedule estimates. Appendix B provides some information on how to execute a PERT analysis.
Allow time for things to go wrong in the overall project schedule. Projects of any complexity will have something go wrong that will take more time. Programming in enough slack time without allowing the team to procrastinate and lose focus is an art, not a science. One way to do this is to add explicit WBS tasks under project management control for resolving variances.
THE OPTIMISM OF PROJECT TEAMS
Project teams tend to underestimate how long it will take to do something. This isn’t because we are lazy or dishonest.
People who gravitate toward project work have a certain mindset. We like to accomplish something new. (Even better to accomplish something that everyone else thinks is impossible!) If we spent all our time thinking about what could go wrong, we would never finish the project, and we would probably never be invited to be a member of another project team.
When you are working on a schedule, question your assumptions. Are you assuming a best-case scenario? What unknowns could come back to clobber us? Make sure your schedule takes realistic estimates and risk assessments into account.
An overly precise schedule is an early indicator of problems in the project planning process.
Precision is very easy to achieve. Accuracy is much harder. You can spend a lot of time tweaking a schedule beforehand, but any nontrivial project schedule will need to be adjusted anyway as difficulties come to light.
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.)
The project scope is a general statement about the size of the project. Beyond that, stakeholders must agree to specific requirements and success criteria.
A requirement is a problem statement. It does not attempt to specify how the problem will be solved; it states the problem in a clear enough way that a knowledgeable person will be able to work toward a problem resolution. A good requirement statement is easy to understand, but hard to misinterpret.
Note Requirement statements are a form of communication. If they are not understood by both the requestor and the implementer, they need to be revisited.
Frequently, stakeholders will try to use these requirements to expand the scope of the project. The project manager must keep a handle on scope creep. If the scope needs to be expanded, stakeholders and decision makers have to allocate the resources to do so or reduce requirements elsewhere to free up the necessary resources.
Note Part of tracking requirements will be tracking the differences between the requirement statements and what actually comes out of the project. These differences are known as variances.
Software engineering makes a distinction between C-requirements (customer requirements) and D-requirements (developer requirements). C-requirements are usually high-level descriptions of behaviors that are wanted or needed; D-requirements are the specific, detailed requirements that developers use to implement the C-requirements.
There needs to be clear mapping between C-requirements and D-requirements. Standards that are based on the IEEE 930-1993 and 830-99 standards for expressing requirements use a unique identifying number for each requirement. For projects that have more than a trivial number of requirements, I recommend that you assign each requirement a number, that each D-requirement specifies a corresponding C-requirement, and implementation work packages reference a D-requirement. Otherwise, you will spend way too much time answering questions about why things are being done this way.
Note In IEEE 930-1993 and 830-99, C-requirements are assigned 2.x numbers, while D-requirements are assigned 3.x numbers in a standard way. For example, subdivisions of “2.1.4” are used to express C-level software interface requirements; subdivisions of “2.1.5” describe C-level communications interfaces, etc.
If your organization has a standard way of expressing requirements, use it. If not, you can do a lot worse than downloading the 930-1993 and 830-99 standards from IEEE and using them as a template for assigning requirement numbers.
Requirements should be expressed in a standard way:
Which project goals have not been made explicit in the documentation?
Which disagreements between team members may delay the project?
What are the underlying architecture and technology infrastructure?
Which standards or other organization requirements must be met?
Are there regulatory requirements that must be fulfilled?
Which expected organizational changes might impact the project estimates or team structure?
Are the definitions clear?
Have all the different teams been represented in the planning discussions?
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:
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:
These can be diagrammed in UML format (see Chapter 13), or they can be written out verbally, as in Example 4-1.
EXAMPLE 4-1: USE CASE EXAMPLE
ID: 2.2.2.1
Summary: Submit personal information in web form
Rationale: Web interface selected as most appropriate way to accept personal information
Actors:
Initial state: End user has main web page displayed on web browser
Actions:
Alternate path: In the event of an error,
Final state: Display
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.
INTERVIEWS TO GATHER REQUIREMENTS
The first step to gathering requirements is to identify who to interview. Generally speaking, the people closest to the business process in question are good people to answer questions about how the business process works.
Another good group of people to interview are the people who manage the application as it currently exists. They probably have a good view about what works and what does not in the current system.
Here are some questions that need to be answered to pull together requirements:
What benefits do we expect from this project?
What problems are we trying to solve?
Who will manage the system when it is complete?
Who are the direct users of the new system?
Who are the indirect customers for the new system?
Who does this system need to talk to? (Where does it get input from? Where does output go?)
What format constraints do we have on input and output?
What performance or Service Level Agreement (SLA) constraints exist for the system?
What sort of pain points exist with the current system?
Are there pain points adjacent to the existing system that can be eased by designing this system a little differently?
Are there training materials for the existing system that we can examine for requirements?
What do typical requests look like for the existing system? How are they currently processed?
Structuring Requirements
Requirements should be identified with a unique requirement number. Especially if there are more than a few requirements, it makes cross-referencing much easier when setting expectations for work packages or user acceptance testing.
It probably makes the most sense to structure requirements in a nested structure, with high-level requirements being broken down into lower-level requirements. See Example 4-2 for a simple example.
EXAMPLE 4-2: REQUIREMENT STRUCTURE
2.15 : Obtain a database server
2.15.1: Server must be compatible with organization standards
2.15.2 : Server must have at least 4 cores
2.15.3 : Server must have at least 4 GB RAM
These numbers need to remain consistent throughout the project; you will drive yourself insane if you keep trying to update all the places a requirement number appears in the project documentation every time a requirement is removed or added. If a requirement is cancelled, the requirement document should be updated to reflect its cancellation, but the number should not be re-assigned.
Nonfunctional Requirements
In addition to describing the functioning of the system (functional requirements), there are a number of nonfunctional requirements that need to be considered. It may be necessary to negotiate some of these. Reaching certain thresholds, for example, may require a larger investment than the customer wanted. In that case, options can be presented as part of the scope conversation.
COMMON NONFUNCTIONAL REQUIREMENTS
Availability. Uptime and network availability requirements for different parts of the system.
Scalability. How quickly and easily additional resources can be brought online.
Portability. How easily the system can be moved. This may include moving it to a different platform or vendor.
Security. What type of security requirements are in place for the system or network communications.
Fault tolerance. How well the system deals with component failures.
Performance. How responsive the system is, and how much throughput capacity it has.
Usability. How user-friendly the system is.
Flexibility. How easy it is to bring additional features or components online.
Data integrity. The level of checking to ensure that data remains consistent and correct.
Part of dealing with requirements is validating that they have been achieved in the final project result. If you specify what the requirements mean when you define them, it makes it much easier for the project team to hit them.
You will need to have representatives of the user community available to answer questions and to directly verify that the requirements have been met in user acceptance testing. The earlier components can be tested, the more time there will be to take care of any variances that appear.
Project Management Plan
The project management plan for each project will be unique. It needs to be complete, but should only include what is needed to complete the project successfully. This is a balance because a simple project will need a lot less detail and structure than a complex multiteam project.
Structure for a Project Management Plan
Depending on the environment where you find yourself, you may have a project management plan template that you are expected to use. Some common standards include templates that are included with Microsoft Project, as well as US Department of Defense standard 2167 and IEEE 1058-1998.
Here are some common sections and ideas that should be included in a project management plan:
Risk Management
The project manager should get agreement to a risk management plan as part of the initial project plan approval. This includes maintaining a register of risks and issues associated with the project.
Some elements to include in a risk management plan are the following:
Note One way to rank risks is to express the likelihood as a percentage, and the impact in dollars. (This may mean translating project delays or man hours into a rough dollar figure.) Multiply those numbers for each risk, and compare the results to rank which risks need the most urgent attention.
For example, if risk A has a 50% likelihood of costing $10,000, and risk B has a 10% likelihood of costing $20,000, then risk A has an expected cost of $5,000 (.50 × $10,000), and risk B has an expected cost of $2,000 (.10 × $20,000). Risk A would be considered the more urgent risk, in this case.
Risks can be dealt with in one of the following ways:
Risks need to be tracked by the project management team. A risk register should be published and made available to the stakeholder community. Project team members should report all known risks to the register to be analyzed, and the project management team should set up interviews and brainstorming sessions early in the planning process to try to identify known risks.
ELEMENTS OF ENTRIES IN THE RISKS AND ISSUES REGISTER
Unique identifier. If a unique number is assigned to each risk, it makes it easier to cross-reference the risk in other project documents.
Seriousness. The seriousness of the risk should be ranked, perhaps with a numerical scale indicating how serious the risk has been evaluated to be, based on its likelihood and potential impact.
Name. The risk should be given a unique short descriptive name for discussion.
Description. The risk should be described, or a document containing a full description can be referenced.
Category. This will indicate which part of the project team needs to deal with the risk or its impact.
Root cause. Chapter 9 discusses how to perform a root cause analysis, if needed for this risk.
Triggers. Symptoms that indicate that the risk may be active.
Responses. Mitigation actions, contingency plans, or other possible responses to the risk.
Owner. The person assigned to deal with the risk.
Likelihood. How likely is the risk to occur? This could be in percentages, or in terms of high/medium/low.
Impact. What is the downside risk?
Status. Has the risk been mitigated or accepted?
As the project progresses, the project manager is responsible for looking at how the dependency relationships are affecting the overall project timeline. In particular, the project manager needs to keep a close eye on the sequence of tasks that make up the critical path.
A dependency is a relationship between tasks that has an impact on how they are sequenced or scheduled.
There are a few different ways that dependency relationships can have an impact on task scheduling. It is important to track the type of dependency, as these can have very different effects on scheduling.
There are several ways to diagram dependencies. Project management software, such as Microsoft Project and GanttProject, will take care of these diagrams for you, as long as you put the dependency information into the project plan. In general, dependency relationships are represented on a network diagram, where the first task is at the tail of an arrow, and the second task is at the point. Depending on the type of network diagram and type of dependency, the arrow location and shape may be different.
The points of interaction between the groups and elements of the project are a particular type of dependency that needs special attention.
When these interfaces are points of contact between two groups, you are responsible for making sure that they are working together smoothly and communicating the information needed so that their respective contributions come together correctly.
The number of interfaces grows very quickly as the number of elements increases. A good project manager is able to identify the critical interfaces early and monitor them throughout the project cycle. When these interfaces break down, that will affect multiple elements of the project plan.
There are certain places in the project plan that are natural places for making sure that the project is remaining on track. These milestones need to be tracked to make sure that the overall project is remaining on schedule. They also should be reported to the stakeholder community to build confidence in the project and a sense of momentum that will help carry the project through to completion.
Milestones need to be specific, measurable, assignable, realistic, and time framed. (Project managers refer to these as SMART milestones.) Beyond that, they need to be well-chosen, to reflect the progress of major phases of the overall project.
Staying on Track
The time estimates in the WBS are an important tool for tracking whether you are on target to hit a milestone. Items on the critical path are the ones that need the most focus, but the critical path may shift as people report different work packages completed or delayed. Make sure to get status on each work package, including time estimates.
Publish the time estimates provided by the project team. If the estimates are not written down and tracked, they will slide. When things are delayed, as they will be, work with the accountable people to find out why and try to identify a way to get the project plan back on track.
Milestones are also appropriate times to review project progress. In the event that the cost and/or schedule are increasing rapidly, these reviews are the time to either adjust the scope, commit the additional resources, or maybe even scrap the project.
These reviews are sometimes referred to as “kill points.” The worst thing to happen to a project is to have its costs spiral out of control, and never to produce anything. If the project starts to go down that path, it may be best to kill it and go back to the “concept” phase to replan.
Each project phase should be considered to be a milestone. At each phase of the project, the project manager is responsible for checking with stakeholders for agreement that the project is meeting the project requirements.
Identify and Schedule Resources
As different resources will be needed during the project execution, the project manager is responsible for lining them up. This includes people as well as facilities, equipment, or vendor participation.
One of the most important duties of a project manager is to look around the corner to see the next approaching pain point, and to arrange to alleviate it before anybody else realizes it is coming.
Stay in touch with the people who are executing the work, and provide opportunities for them to approach you with problems. These problems can have downstream effects on resource requirements and scheduling for other parts of the project.
Scope and requirement changes are sometimes necessary, but they are costly in both money and time. Changes should not be undertaken lightly. The project manager is responsible for making sure that any changes to scope or requirements have complete buy-in, including explicit commitments of the resources needed to implement the changes.
Part of a project manager’s job is tracking these changes and considering their impact on other parts of the project. The project as a whole may be delayed as a result of a change to a particular component or task.
During the project, the project manager will need to identify, evaluate, and manage the changes that are proposed during the project. Team members need to understand that changes need to go through the approval process; otherwise time will be wasted with intergroup conflict, and it may be necessary to destroy something that was close to completion if it includes unauthorized changes.
Changes can be the most contentious part of a project. Project managers need to be well-organized and retain documentation about changes that are considered, rejected, accepted, and implemented. Documents to be tracked include:
It is unwieldy to get approval from every stakeholder for every change. Most changes would be reviewed and approved by a change control board (CCB) made up of representatives of the key stakeholder groups. It usually makes sense to have regularly scheduled CCB meetings so that team members know when changes need to be submitted, and when an answer can be expected. In a time-sensitive project, CCB review meetings should be scheduled frequently.
The CCB needs to include enough representation from the key communities to ensure that risk assessments and necessary communications have been carried out properly. The project management team, user community representatives, stakeholder representatives, engineering and development resources, and other specialty communities should be represented on the CCB.
Team members also will need guidance on the format that is expected for change requests.
Reporting Project Status
Execution is great, but the plug will be pulled on the project unless the project sponsor and the key stakeholders are able to see concrete progress. It is the project manager’s responsibility to provide accurate reports of the project status.
You will want to develop standard templates or a dashboard for reporting project status. The goal is to allow stakeholders to identify project status at a glance, preferably without interrupting you for a personalized update.
Killing a project is a huge decision, especially if a project has been allowed to meander out of control for some time. Being the project manager for a large failed project is a career limiting move. If you keep tight control from the outset, you are much less likely to have to kill a project further along.
The crisis moment when people decide to kill a project is almost never the first sign of trouble. Trouble should have appeared earlier, when someone realized that the dependency relationships were wrong, or the amount of time for a task was totally wrong, or that something happened that was going to blow out the budget. When things go wrong, they will not fix themselves. Jump in right away to get the project back on a firm footing.
Most people are reluctant to come forward and say that a project is in trouble. One way of identifying projects that are in trouble is known as earned value management (EVM).
EVM is a method for tracking the costs of a project and making sure that the money spent on the project is being matched by progress on the project. EVM involves calculating the following:
The following are the formulas used to calculate the variances using the EVM.
EXAMPLE 4-3: EXAMPLE EVM CALCULATION
Assume that the amount expected to have been spent to date is $10,000, that the actual amount spent was $15,000, and that the percentage of planned work completed so far is 50%.
EV = $10,000 × 0.50 = $5,000
CV = $5,000 – $15,000 = –$10,000
SV = $5,000 – $10,000 = –$5,000
CPI = $5,000/$15,000 = 0.33
SPI = $5,000/$10,000 = 0.5
The key numbers are:
EAC = BAC/.33 = BAC × 3 (i.e., the cost is expected to come in three times as high as budgeted.)
ETC = (original time estimate)/.5 = (original time estimate) × 2 (i.e., the time is expected to come in as twice as long as originally estimated.)
Example 4-3 shows EVM calculations for a project that is running over budget and behind schedule. If someone told you that the project was going slower than expected and still running over its budget, you would know that the project was in trouble. EVM gives you a quantitative tool to estimate just how bad the damage is, and to compare projects that are in trouble.
To deliver a quality product at the end of the project, you have to track the quality of the deliverables throughout. This will involve having a test plan in place that will validate the different deliverables as they are reported complete.
Beyond checking the quality of the deliverables, you also have to check that the interfaces between different components work properly.
Most important of all, you have to verify that the project meets the requirements of the user community. This is best checked as thoroughly as possible while the project is running, rather than delivering a complete package at the end for verification. To the extent that prototyping and test harnesses can be used to allow users to check components, you will be able to avoid unpleasant surprises at project delivery time.
A high-quality project deliverable will both conform with the requirements for that deliverable, and will also be fit for use in the manner intended. If both things are not true, the quality of the deliverable is not acceptable.
To have high quality, you need your planning process to support good requirements gathering, your quality assurance process needs to guarantee that deliverables are of acceptable quality, and your quality control process needs to identify and implement ways to improve quality.
Quality is usually measured by testing. If the detailed requirements are complete, the test plan can follow what is specified for each requirement. Each requirement should include one or more acceptance tests for determining whether the requirement was met.
Some important criteria for acceptance tests are:
Testing needs to be performed at several different levels as project components are delivered. These can be combined to the extent practical, in order not to leave rework or major problems to be discovered at the last possible moment.
The earlier in the process an error is caught, the less expensive it will be to fix it. The amount of time saved by an appropriate review and testing schedule will more than pay for itself over the course of the project.
Reviews are critical. It is impossible to simply “test in” good quality. Good quality starts with good requirements and a good design, then continues through the rest of the build process. Good quality is built in from the ground up.
When management decides to cut time from the project, testing is usually the first target. That is a false sense of savings; the time cut from the project plan is likely to be more than wasted in dealing with the problems that were not caught earlier in the process.
Sometimes problems emerge in testing that need to be identified. Chapter 9 discusses tools that can be used in group troubleshooting and root cause analysis sessions.
When the project is delivered, the project manager’s job is not done yet. There are still a few more tasks that should be undertaken to wrap up the project.
Summary
Project management is a discipline that every IT leader should study. It provides a structured, standard way to organize projects. Your organization can benefit from the discipline to use a standard project management process.
Discussion Questions
Think of a project you have been involved in.
Further Reading
Berkun, Scott. Making Things Happen. Sebastopol, CA: O’Reilly, 2008.
Braude, Eric J. Software Engineering: An Object-Oriented Perspective. Danvers, MA: Wiley, 2001.
Schwalbe, Kathy. Information Technology Project Management. Boston, MA: Thompson, 2006.
Stellman, Andrew, and Jennifer Greene. Applied Software Project Management. Sebastopol, CA: O’Reilly, 2006.
18.191.176.5