Project Management

Project pre-planning
10 open source projects worth checking out 1
Why critical path is critical to project management 3
Use this process to estimate a project’s effort hours 5
10 techniques for gathering requirements 6
Five tips for building a Work Breakdown Structure 8
Make Work Breakdown Structure easier with the materials you use 9
Project management: Pin down how your client defines quality 10
10 ways to avoid stupid project estimates 11
Facilitate a meeting to define what success looks like for your project 14
10 ways to avoid mistakes during project development 18
Use a pilot project to confirm estimates and lessen risks 21
Mining project requirements—techniques to use
before and after an interview 22
Use prototyping to visualize project requirements 24
10 best practices for successful project management 25
JAD sessions will speed up the project definition process 29
Don’t fall prey to these false project requirements 31
10 ways to avoid stupid project estimates 32
10 ways to overcome resistance to project collaboration software 35
Categorize high-level requirements into use
case titles for better project 37
A four-step prescription for writing better project plans 40
During the Project
10 ways to get a slipping project back on track 42
10 signs that your project is about to be cut 45
Sustain and broaden customer focus outside of your projects 48
Create and sustain a customer focus within projects 51
10 tips for meeting IT project deadlines 53
10 reasons why use cases are indispensable to your 55
software development project
10+ project management mistakes (and what you can learn from them) 58
10+ things that can send an IT project off the rails 61
10 signs that you aren’t cut out to be a project manager 63
10 ways to effectively estimate and control project costs 65
Top five reasons organizations fail at project management 69
Beware of when “completed” activities aren’t really completed 71
See effect of dependent risk by using a decision tree 72
Apply work breakdown structure techniques to organize a program 74
Supervise larger projects with a schedule management plan 75
Look at four ways to set precedence relationships in your schedule 77
Create a risk contingency budget using Expected Monetary Value 79
Use a Fishbone Diagram to attack complex problems 80
A primer on projects, programs, and portfolios 82
Four tips for using metrics on your project 84
Manage project time requirements with these methods 86
Don’t wait to address performance problems on a project 88
Master these 10 processes to sharpen your project
management skills 90
Mining project requirements - techniques to use 99
before and after an interview
Ensure requirements are tracked throughout a project 101
Use gate reviews to validate that you’re ready for the next
phase of your project 102
Three warning signs that your project is doomed 104
Use the tradeoff matrix to foster collaboration in agile projects 107
10 things you should do near the end of a project 109

Agile project management tips

Four variants of agile development methods 111
Five agile project management migration tips 115
Adaptive Project Framework: A new level of agile development 118
Agile reporting methods for project managers 121
Agile drivers for new project management tools 124
Get an overview of the Scrum agile project approach 126
Take positive risks to gain project benefits 128
Find errors as early as possible on your project 129
Inadequate quality management will result in project problems 131
Microsoft Project 2007
Add a custom report in Microsoft Project 2007 133
Add the Late Indicator tool in Microsoft Project 2007 135
Identify slipping and unstarted tasks with Microsoft Project filters 138
Importing a vendor’s Excel schedule into Microsoft Project 140
Identify late tasks with this custom Microsoft Project filter 143
Scheduling project uncertainty with LiquidPlanner 147
Considerations when integrating Microsoft Project
and PPM solutions 150
Build a customized Gantt chart view in Microsoft Project 152
Build milestone charts faster with MindView 3 Business software 155
How to use project data to develop a better estimation matrix 158
Export project data for future effort estimation 160
View the critical path in Microsoft Project 163
Using a fixed duration task type in Microsoft Project 166
Confirm your Microsoft Project Schedule is ready for EVM 168
Project pre-planning 1
10 open source projects worth checking out
How many open source projects are out there? Thou-
sands upon thousands. And out of all those projects, how
many are worth paying attention to? Thousands? Hun-
dreds? If you remove the usual suspects (Linux, Apache,
MySQL, PHP, GIMP, OpenOffice, Firefox, etc.), you can
really start paring down the list. Here are 10 open source
projects you might never have heard of — but really
should check out.
1: OpenBravo
Are you looking for your next ERP application? If so, do
not overlook OpenBravo. This tool is a small-footprint
powerhouse that includes integrated accounting, sales/
CRM, procurement, inventory, production, and project/
service management. OpenBravo also features single-
instance to multiple tenants, organizations, localizations,
and warehouses. It is every ERP tool you will need in one
open source toolbox. If just want to evaluate it, you can
try a virtual machine with OpenBravo. But to download a
package, you will have to walk through a questionnaire.
Warning: Someone might try to sell you something!
2: OpenNMS
OpenNMS should have no problem winning you over. This
tool is a serious network management platform. Open-
NMS offers three main areas: service polling, data collec-
tion, and event/notification management. Its feature list
is pretty impressive and includes node listing, searches,
outages, path outages, events, alarms, surveillance, and
distributed status. If you need to be sold on this product,
hop on over to the OpenNMS Demo page (user/password
“demo”) to see what this tool is all about. OpenNMS will
run on Linux, Solaris, OS X, and Windows (2000, XP, 2003).
3: elgg
Elgg is an open source social networking platform that
powers numerous social networking sites. As many
companies move to offer in-house social networking, you
would do well to invest a bit of time and effort into this
open source project. The elgg social networking platform
offers profiles, notifications, groups, blogs, embedded
media, files, microblogging, pages, external pages, and
more. If you’re looking for a means to improve you com-
pany morale but don’t want users logging on to Facebook
or MySpace, give this open source social networking
platform a try.
4: Magento
Magento is one serious ecommerce tool. This isn’t your
Drupal-ecommerce-module-level ecommerce tool — this
one can stand up with the big boy platforms (and knock
some of them down). Magento features marketing/pro-
motion tools, site management, analytics and reporting,
catalog management, catalog browsing, product brows-
ing, mobile solutions, checkout, shipping, payment, and
more. Magento was voted “Best New Project” on Source-
Forge (2008) for a reason. With community and enterprise
editions, there is a solution for everyone. NOTE: While
the Community edition is free (and is missing numerous
features), the Enterprise edition does have a price tag
(and a steep one at that: $8,900 per year!)
5: dotProject
DotProject is a Web-based project management tool that
offers the features you’d expect — and more. The feature
list includes user management, trouble-ticket system (in-
tegrated voxel.net Ticketsmith), client/company manage-
ment, project listings, hierarchical task lists, file repository,
contact lists, calendar, forum, and a permission system.
What stands out with dotProject is its clean and simple
user interface.
6: Heartbeat
Heartbeat is the heart of the Linux High Availability
project. It’s the piece of the HA project that performs
death-of-node detection, communications, and cluster
management. Heartbeat is a daemon that provides the
cluster infrastructure so that peer machines will know the
1
status of all cluster resources. Of course, Heartbeat isn’t
much good without a Cluster Resource Manager (CRM).
Since Hearbeat is a piece of the HA project, you can be
sure there is a CRM tool ready. Although Heartbeat ships
with a minimal CRM, a new project was spun off, Pace-
maker, that serves as the CRM for the Heartbeat founda-
tion. If you are looking for an open source
clustering solution, this might be the ticket.
7: Enomoly
Enomoly offers a cloud computing solution for any size
environment. If you want to get to the source, however,
you have to use the Community edition. This version is
for SMBs and smaller enterprise use. With this browser-
based management tool, you can design, deploy, and
manage virtual applications within a cloud environment.
You can plan and simplify deployments and automate
virtual machine scaling and load-balancing. If you are
a developer, you will appreciate the fact that Enomoly
includes links to both its core APIs.
the Open Source edition. With the Eucalyptus cloud com-
puting solution, you are getting more than just the means
to serve up cloud apps — you can also control both the
network and the storage infrastructure. Eucalyptus works
with Ubuntu, OpenSuSE, Debian, and CentOS and sup-
ports both Xen and KVM hypervisors.
10: Google Web Toolkit
Developers may want to consider adding Google Web
Toolkit to their arsenal. You can use it to write a front end
for an app in Java and then have GWT compile the source
into a highly optimized JavaScript. And since GWT is
open source, you can join the Google Webkit Community
and contribute modifications for the project.

8: Nuxeo
Nuxeo is an outstanding document management system
that is incredibly feature rich and simple to install. Nuxeo
has so many features, the best way for you to see them all
is to go to the Nuxeo Feature List page. With the Nuxeo
document management system, users can work either
on- or offline (working offline requires an uploading of
content). Users can simply drag and drop content from
desktop to Web browser for content capture. It doesn’t
get much easier. Nuxeo is also offered in a cloud com-
puting edition, which eliminates the need for storage,
hardware infrastructure, or server availability. The cloud
edition of Nuxeo was built with the Amazon AWS.

9: Eucalyptus
Eucalyptus is another entry in the open source cloud
computing space. There are two versions of this solution:
Open Source and Enterprise. Naturally, we are looking at

2
Why critical path is critical to
project management
When I was a business analyst working on a human
resource talent acquisition implementation, six weeks out
from the launch date the project manager rushed us into
a room and asked us to figure out the critical path. I had
heard the term critical path before, but I didn’t really un-
derstand what it meant. I knew the project was critical to
the HR organization and thought everything on the project
was on a critical path.
Project managers will be amused that we were trying to
figure out the critical path with six weeks before launch
rather than prior to project execution. In hindsight, the
project manager should’ve known the critical path earlier
and been monitoring the schedule’s progress. I still find
it puzzling that the project manager asked a bunch of
business and system analysts to determine the project’s
critical path.
It wasn’t until I shifted my career into project manage-
ment that I gained a better understanding of the critical
path and its impact to a project. The Project Management
Body of Knowledge (PMBOK) defines the critical path as
“the sequence of schedule activities that determines the
duration of the project.” Project managers can also apply
the critical path methodology technique to “determine the
amount of float on various logical network paths in the
project schedule network to determine the minimum total
project duration.”
Critical path explained
Figure A
Critical path in Microsoft Project
If you’re just as confused by the PMBOK speak as I was,
let me restate it in a way that’s easier to understand. The
critical path is simply all the tasks that determine the end
date in your project schedule. If one of those tasks is late
by one day, then your project end date will be extended by
one day. Oftentimes, there will be tasks that are not on the
critical path; this is due to the slack in the project schedule.
If you refer to your current schedule, you can examine the
Gantt chart and quickly identify the tasks that have some
float compared to the tasks that have no slack.
Slack is the amount of time a task can be delayed without
impacting the start date of a subsequent task. The critical
path methodology is simply a technique to identify all the
tasks that will directly impact the project end date.
Figure A depicts a Gantt chart with a set of tasks on the
critical path.
Critical path in Microsoft Project
In Figure A, there are five tasks in the project schedule
and Task 4 is not on the project’s critical path. If Task 1, 2,
3, or 5 is delayed, then the entire project will be delayed.
If Task 4 is delayed, it has seven days of free slack before
it will start having an impact on the schedule. Since Task
5 is three days in duration, Task 4 could have an actual
duration of 10 days before it becomes part of the project’s
critical path. If it exceeds 11 days, Task 4 will create a
new critical path.
3
I’ll admit I’m reluctant to create a network diagram and
Critical path and
start the forward and backward pass mechanics. Tools
network sensitivity
are invented for a reason and, fortunately, Microsoft Proj-
If you want to learn about the critical path and network
ect can support forecasting, what-if analysis, and detailed
sensitivity, read my article on Network Sensitivity and the
scheduling metrics along the critical path. By switching
Critical Path. The article features the sample Microsoft
to different views and formatting the Gantt charts, you
Project file if you want to experiment with adjusting the
can quickly identify and monitor the tasks on the project’s
critical path.
critical path.

Figure B depicts the free slack in Microsoft Project. All the

tasks on the critical path have zero slack in their schedule
and that’s why these tasks drive the end date. Task 5 has
7 days of slack and is not included on the critical path. By
increasing or decreasing duration on specific tasks, you
can see the adjustments in the critical path.

Critical path free slack

In my next column, I’ll show you how to identify the criti-
cal path in Microsoft Project and use the different views to
monitor and track the critical path.

Figure B

Critical path free slack

4
Use this process to estimate
a project’s effort hours
There are three early estimates that are needed for a
project: effort, duration, and cost. Of the three, you must
estimate effort hours first. Once you understand the effort
that’s required, you can assign resources to determine
how long the project will take (duration), and then you can
estimate labor and non-labor costs.
Use the following process to estimate the total effort
required for your project:
1: Determine how accurate your
estimate needs to be.
Typically, the more accurate the estimate, the more detail
is needed, and the more time that is needed. If you are
asked for a rough order of magnitude (ROM) estimate
(-25% - +75%), you might be able to complete the work
quickly, at a high-level, and with a minimum amount of
detail. On the other hand, if you must provide an accurate
estimate within 10%, you might need to spend quite a bit
more time and understand the work at a low level of detail.
2: Create the initial estimate of
effort hours for each activity and
for the entire project.
There are many techniques you can use to estimate effort
including task decomposition (Work Breakdown Structure),
expert opinion, analogy, Pert, etc.
3: Add specialist resource hours.
Make sure you include hours for part-time and specialty
resources. For instance, this could include freelance people,
training specialists, procurement, legal, administrative, etc.
4: Consider rework (optional).
In a perfect world, all project deliverables would be cor-
rect the first time. On real projects, that usually is not the
case. Workplans that do not consider rework can easily
end up underestimating the total effort involved with
completing deliverables.
5
5: Add project management time.
This is the effort required to successfully and proactively
manage a project. In general, add 15% of the effort hours
for project management. For instance, if a project estimate
is 12,000 hours (7 - 8 people), a full-time project manager
(1,800 hours) is needed. If the project estimate is 1,000
hours, the project management time would be 150 hours.
6: Add contingency hours.
Contingency is used to reflect the uncertainty or risk
associated with the estimate. If you’re asked to estimate
work that is not well defined, you may add 50%, 75%,
or more to reflect the uncertainty. If you have done this
project many times before, perhaps your contingency
would be very small — perhaps 5%.
7: Calculate the total effort by adding
up all the detailed work components.
8: Review and adjust as necessary.
Sometimes when you add up all the components, the esti-
mate seems obviously high or low. If your estimate doesn’t
look right, go back and make adjustments to your estimat-
ing assumptions to better reflect reality. I call this being
able to take some initial pushback from your manager and
sponsor. If your sponsor thinks the estimate is too high,
and you don’t feel comfortable to defend it, you have more
work to do on the estimate. Make sure it seems reasonable
to you and that you are prepared to defend it.
9: Document all assumptions.
You will never know all the details of a project for certain.
Therefore, it is important to document all the assumptions
you are making along with the estimate.
This type of disciplined approach to estimating will help
you to create as accurate an estimate as possible given
the time and resources available to you.
10 techniques for gathering requirements
It’s difficult to build a solution if you don’t know the
requirements (in spite of the fact that many teams still try
to do it today). The “elicitation” step is where the require-
ments are first gathered from the client. Many techniques
are available for gathering requirements. Each has value
in certain circumstances, and in many cases, you need
multiple techniques to gain a complete picture from a
diverse set of clients and stakeholders. Here’s a look at
some of the approaches you can take.
1: One-on-one interviews
The most common technique for gathering requirements
is to sit down with the clients and ask them what they
need. The discussion should be planned out ahead of
time based on the type of requirements you’re looking
for. There are many good ways to plan the interview, but
generally you want to ask open-ended questions to get
the interviewee to start talking and then ask probing ques-
tions to uncover requirements.
2: Group interviews
Group interviews are similar to the one-on-one interview,
except that more than one person is being interviewed
— usually two to four. These interviews work well when
everyone is at the same level or has the same role. Group
interviews require more preparation and more formality
to get the information you want from all the participants.
You can uncover a richer set of requirements in a shorter
period of time if you can keep the group focused.
3: Facilitated sessions
In a facilitated session, you bring a larger group (five or
more) together for a common purpose. In this case, you
are trying to gather a set of common requirements from
the group in a faster manner than if you were to interview
each of them separately.
4: Joint application
development (JAD)
JAD sessions are similar to general facilitated sessions.
However, the group typically stays in the session until the
session objectives are completed. For a requirements JAD
session, the participants stay in session until a complete
set of requirements is documented and agreed to.
5: Questionnaires
Questionnaires are much more informal, and they are
good tools to gather requirements from stakeholders in
remote locations or those who will have only minor input
into the overall requirements. Questionnaires can also
be used when you have to gather input from dozens,
hundreds, or thousands of people.
6: Prototyping
Prototyping is a relatively modern technique for gathering
requirements. In this approach, you gather preliminary
requirements that you use to build an initial version of the
solution — a prototype. You show this to the client, who
then gives you additional requirements. You change the
application and cycle around with the client again. This
repetitive process continues until the product meets the
critical mass of business needs or for an agreed number
of iterations.
7: Use cases
Use cases are basically stories that describe how discrete
processes work. The stories include people (actors) and
describe how the solution works from a user perspec-
tive. Use cases may be easier for the users to articulate,
although the use cases may need to be distilled later into
the more specific detailed requirements.
8: Following people around
This technique is especially helpful when gathering infor-
mation on current processes. You may find, for instance,
that some people have their work routine down to such
a habit that they have a hard time explaining what they
do or why. You may need to watch them perform their
job before you can understand the entire picture. In some
cases, you might also want to participate in the actual
6
work process to get a hands-on feel for how the business
function works today.

9: Request for proposals (RFPs)

If you are a vendor, you may receive requirements through
an RFP. This list of requirements is there for you to com-
pare against your own capabilities to determine how close
a match you are to the client’s needs.

10: Brainstorming
On some projects, the requirements are not “uncovered”
as much as they are “discovered.” In other words, the
solution is brand new and needs to be created as a set
of ideas that people can agree to. In this type of project,
simple brainstorming may be the starting point. The
appropriate subject matter experts get into a room and
start creatively brainstorming what the solution might look
like. After all the ideas are generated, the participants
prioritize the ones they think are the best for this solution.
The resulting consensus of best ideas is used for the
initial requirements.

7
Five tips for building a Work
Breakdown Structure
A Work Breakdown Structure (WBS) is the best way to
3: Break activities into two or more
understand the detailed work of the project when you detailed activities
have to build a schedule from scratch. It’s used to break I’ve seen teams that break one activity in the WBS into
the project down into the major phases, deliverables, and only one activity at the next level. In my opinion, this
work components that will be built by the project. These doesn’t make sense because then the detailed activity
work components can then be broken down into the ac- represents the same work as the prior summary activity.
tivities that are required to build them. The WBS is not the This doesn’t buy you anything.
same as the final schedule (which requires sequencing,
resources, estimated effort, estimated duration, etc.). 4: Make the final detailed
activities action oriented
Here are five tips to keep in mind when building your WBS: The detailed activities on your WBS (the ones that are not
broken down further) are ultimately moved to your sched-
1: Create a WBS dictionary for large
ule. For that reason, it’s easier if the detailed activities in
projects
your WBS are action oriented — just as activities in your
Normally you wouldn’t need a WBS dictionary, but if your
schedule would be. For example, instead of describing a
WBS has hundreds (or thousands) of detailed activities,
detailed WBS activity as “meeting,” you should state it as
there may just be too much to keep track of by hand. In
“schedule a weekly meeting.” Instead of having a WBS
this case, it might make sense to place all of the impor-
detailed activity for “Testing Plan,” you should state it
tant information in a WBS dictionary. The dictionary helps
instead as “Create Testing Plan.” In this way, the detailed
keep track of all of the summary and detailed activities,
activities can be moved to the schedule with a minimum
including a short description, the WBS numeric identifier
of wording changes.
(1.1, 1.1.1, 1.1.2, etc.) and the estimated effort. If you
enter your WBS dictionary into a specialized tool, the tool 5: Don’t place requirements
can also help to keep track of changes to the WBS as well. on the WBS
If you place a deliverable on your WBS, you can break
2: Use the summary activities
this deliverable down into the activities that are required
as milestones
to create it. You don’t break a deliverable down into
Your WBS should contain both detailed and summary
the requirements that describe it. Requirements do not
activities. (A summary activity is one that is broken
belong on a WBS. Only deliverables and activities belong
down further; a detailed activity is one that is not broken
on the WBS.
down further.) Although a schedule usually includes only
detailed activities, it makes sense to include the summary By using these five techniques, you will save you time and
activities as milestones (i.e., markers signifying that a deliv- rework on your next WBS.
erable or set of deliverables is complete). A summary activ-
ity can be used as a milestone since it would indicate that
all of the underlying detailed work has been completed.

8
Make Work Breakdown Structure easier
with the materials you use
Almost all project schedules are built using a Work Break-
down Structure (WBS). When you’re building a complex
schedule, you don’t sit down and identify fall of the activi-
ties starting with the first one and ending with the lastYou
probably first enter your high-level work, then come back
later and start filling in the detailed work. This is basically
the WBS technique.
If the project manager is the only person creating the
schedule, it’s very likely that the WBS will be created
at the same time the work is entered into your project
management scheduling tool. However, in many cases
the project manager doesn’t know enough to lay out the
entire schedule from scratch. In this case, a small group
of people may be required to complete the WBS.
When you’re creating a WBS in a group setting, it may be
best to use Post It notes and a blank wall to create the
first draft of their Work Breakdown Structure.
This technique is very easy. After you get the appropriate
people into the same room (project team members and
clients who have the expertise to build the WBS), you
start to build it. You can start off by writing the names of
the major deliverables on Post IT notes, one deliverable per
sheet. Make sure the attendees agree on the major deliver-
ables to begin with. If any of the deliverables are very large,
you can create new notes that describe the deliverable at
the lower level of individual work products. These work
products are arranged under the higher-level deliverable.
The deliverable needs to be identified at a level low
enough that you understand what it takes to build it. In
general, two levels should be enough to identify your
deliverables. One level is typical.
Next, for each deliverable, describe the activities that
must take place to complete it. Each activity goes on a
9
separate note. These activities are arranged under the
specific deliverable they refer to. If you have a sense for
the order that the activities need to be completed, you
can arrange the notes sequentially. However, this isn’t vital
at this point. The important thing is to identify all the work.
Look at the activities that are required to build each deliv-
erable (or work product) and estimate the work associated
with each activity. If the effort associated with an activity
is larger than 80 hours (or whatever high-level threshold
you set), you would break that activity into a set of smaller
activities. Each of these activities is represented by new
Post It notes under the higher-level activity (which now
becomes a summary activity).
Continue with this process until the work required to
complete all of the deliverables are defined, as best you
know at that point. Some simple deliverables may take
one or two levels of work breakdown. Others may take
three, four, or more.
The advantage of this approach is that your team can
actually see the work and they can help ensure all the
work is identified to complete the project. The Post It
notes also give you the ability to easily move things
around. If you add an activity and then decide to remove
it, you just pick up the sticky sheet. Likewise, if a deliver-
able or group of activities is in the wrong place, you just
move the sticky sheets to where they need to be.
When you’re all done, you can enter the detailed work ac-
tivities into your workplan management tool. Remember
that the WBS is not the same as the schedule. The WBS
is only the technique you use to understand the work at a
low level. When the WBS is completed you can continue
to build your schedule by sequencing the activities, as-
signing resources, estimating costs and duration, etc.
Project management: Pin down how your
client defines quality
A good definition of quality management is “to first There will be role-based security so people can
understand the expectations of your customer in terms of only see data that is consistent with their roles.
quality and then put a proactive plan in place to meet that
People sometimes ask where this information gets docu-
level of quality.” The first part of this definition can be the
mented. It’s easy - these end up being detailed quality
toughest - understanding what quality means to your
requirements and they’re captured along with all of the
customer.
other project requirements.
Your customer may only tell you that you should build a
Most project teams don’t make it a point to capture all
“good quality solution” or you should build a solution with
of their quality requirements. Most project teams focus
an “acceptable level of quality.” Your response to that
requirements on understanding features and functions. If
should be “Great. But what the heck does that mean?”
you focus on features and functions, many of the quality
The customer needs to state that the project solution
requirements may come out as well - usually by acci-
needs to be:
dent. But if your team is trying to practice formal quality
Reliable management, you should have a discussion with your
clients that focuses on the broader and more specific set
Easy to use
of quality requirements.
Easy to maintain when completed

Available when needed

Flexible for future needs

Intuitive / easy to understand

Secure

Minimally defective (Doesn’t have to be perfect)

Once you’ve gotten that far, you need to help the cus-
tomer drill down further. Let’s say that the customer thinks
that a good quality solution needs to be “secure.” Further
probing might reveal that for the customer, this means

The solution should be place in a secure room

with password access

Only authorized people can login

The password must change every thirty days

10
10 ways to avoid stupid project estimates
Projects run on estimates. You either have to provide a great opportunity to assess their assumptions.
estimates of things such as how much effort your task
3: Challenge the numbers
will require or you will need such information from others.
Push back. Ask questions. Project managers seem to do
Unless you’re in one of a small handful of roles, you will
this pretty naturally, but challenge the developer or devel-
surely come to rely on estimates of others, even if it’s
opment team to explain why they think it will take so long.
just to frame your own estimates. And if you’re a project
If they can justify their estimate, at least you will know
manager, the estimates of others are probably all you
that they gave it some thought. If they can’t, perhaps they
have to work with.
should be thinking about their estimate some more before
Overall, project estimates are only as good as the you start relying on their figures.
individual estimates associated with the component
Don’t be surprised if the estimate actually goes up. It
tasks. As much discussion as there is on the estimation
would not be the first time I’ve seen a discussion with
process, there isn’t a great deal of information on getting
developers expose previously undiscovered project tasks.
better estimates from others. Here are a few ideas to help
While not great news, it’s still better to find out about this
you see this aspect of estimating more clearly -- and help
sooner rather than later. Left hidden, those tasks would
you avoid leading your project astray before it ever starts.
have surely destroyed the timeline when they came to the

Vetting the estimates you surface and jumped onto the critical path.

get today
4: Measure
1: Let history be your guide Okay, you know your developers are always missing their
It is true: History does repeat itself. I can’t tell you the
estimates, but by how much? If you aren’t measuring it,
number of times I’ve seen developers give an estimate
you really don’t know whether you have a big problem
of two days and actually take four. There’s nothing wrong
-- or maybe don’t have a problem at all. This also ties into
with that, because there was probably four days’ worth
the history suggestion above. How long does it usually
of work to begin with. The problem is that I also see
take? You don’t know unless you track this information.
people in meetings repeatedly believing them. If it has
taken twice as long as the estimate the last five times an Metrics also go a long way toward improving estimates.

estimate was given, why would anyone think the estimate Like any process, you can’t improve it if you don’t mea-

will hit this time? Beats me, but some people continue to sure it. Unfortunately, a deep dive into this topic would

fall for it. Unlike the stock market, past performance can be an entire article (or two) in itself. But if you don’t have

be an indicator of the future. a clue where to start, just start capturing expected date
versus actual delivery date. You might be surprised by the
2: Ask for details (proof) patterns that develop
Learn the justification for an estimate. If you ask why they
think it will take two days, and you get a reasonable task-
5: Bracket the work
This is for those who just can’t come up with a time
by-task break down of the two days’ work, two days may
estimate for the work. First, try helping them break
be right on the mark. But if your developers just shrug
down their work into smaller, more manageable, tasks.
their shoulders, it may be time to worry. This also provides

11
Next, you may find it useful to use a simple bracketing
Improving future estimates
technique to help the person zero in on the figure that is
8: Give feedback
appropriate. “Is five days enough time?” “Can you do it
You have captured task estimates, and you have tracked
in less than 10?” Continue in this fashion until you get a
actual. From this, you may have learned that certain
figure that everyone is comfortable with. Of course, you
groups always underestimate by 25 percent. That is
should be challenging and asking for details throughout
certainly good to know, but don’t let the value stop there.
this process.
Provide feedback to the team members. Help them

6: Get a second opinion identify patterns in how they estimate and challenge them

When you’re hiring a builder, they say you should get to find the root cause of their bad estimates. Generally

several estimates, throw out the highest and the lowest, speaking, people really do want to do a good job, so

and then go with the one in the middle. There might be provide them the tools and a few suggestions. Your folks

something to that approach. When working with a team, will be able to take it from there.

you’re probably getting your estimates from the team’s

point person -- a lead developer, for example. While this
is efficient, it may add some risk to the accuracy of any
estimate you receive, especially if there is a wide variance
in the estimates of the individual team members. You
may be getting the result of a faulty team consensus, a
blatant falsehood to avoid having to face some
development reality, or an estimate flawed by an
innocent miscommunication.
If you have reason to suspect an estimate may be off, or
if the team has a bad track record for this sort of thing,
a second opinion may be in order. Seek an informal read
from other members of the team. If you run the team
estimate past an individual developer, and he wrinkles
his nose at it, you may have some more digging to do. If
everyone is of a like mind, you probably have as good a
number as you can expect.
9: Reward and penalize
Penalize the bad estimate, not that a task estimate is
too long. When estimates are shortened, it’s generally
because that shorter number is what’s expected. That is
where the “If all goes well, it will take…” comes from. Be
serious. When was the last time “all went well”? There’s
nothing wrong with qualifying an estimate, but adding an
unrealistic assumption as a way to give a bad estimate
only hurts the project. You want to drive toward behaviors
that give better estimates. Celebrate when estimates are
hit. When estimates are missed, you don’t need to tar and
feather the offenders, but you can treat it as a remedial
education opportunity (the very act of which will be a
penalty of sorts).
Be careful about rewarding beating an estimate differently
from hitting it. If you create the situation where it is better
to beat an estimate than simply meet it, you will create an

7: Remember that two heads are incentive for overestimating.

better than one
Run your figures past someone who might have experi-
10: Develop a culture
Using the correct rewards and penalties goes a long
ence with your type of project. If this person is not on your
way toward establishing the right culture, but what is the
project, all the better. Perhaps you’re a sucker for good
right culture? Certainly, it’s one in which those providing
news. Perhaps they are telling you what you want to hear.
estimates feel safe in providing accurate information as
An objective third party is exactly what you need to free
opposed to providing the information they believe super-
you of your bias and give you a clearer view of reality.
visors want to hear. However, it must also be one in which

12
everyone strives to improve the quality of their estimates
and the notion of providing a bad estimate is as bad as
providing bad program code. Managers must also respect
those providing them with information, once those people
have proven themselves. Ultimately, if you can get peer
pressure to “manage” the estimates, your job will become
considerably easier.

Improve your project... one

estimate at a time
You can’t run a project well with bad estimates, any more
than you can build a house with faulty bricks or lumber.
Fortunately, you don’t need to do everything yourself
(nor could you) to get estimates you can trust. Exercis-
ing the simple ideas above will help you filter out the bad
numbers you get today, improve the numbers you get
tomorrow, and generally make your life a whole lot better
-- at least as far as your project is concerned.

13
Facilitate a meeting to define what
success looks like for your project
Although most projects start enthusiastically, optimism
fades quickly unless an analysis and design team gets
traction and learns where it is going. Working from a
project charter, the team’s next step is defining typically,
“What does success look like?” These high-level require-
ments help clarify the project’s vision and give the team a
focus. Many business analysts employ group facilitation to
elicit these requirements. This blog post summarizes some
of the steps you might follow in facilitating such a meeting.
The importance of “group think”
Long a mainstay of business analysis, one-on-one inter-
views with stakeholders is a standard business analysis
tool. Typically, each stakeholder represents to you the
interests of his or her own business unit and measures the
project by what the unit may gain or lose. Accumulated,
these one-on-one interviews make me think of the ancient
Indian story of “The Elephant and the Seven Blind Men.”
Perhaps you remember the story. One blind man judged
the elephant to be a large snake because of its trunk. An-
other claimed the elephant was a tree because of its leg,
and so on. Is there method to develop consensus among
opinionated individuals? I’ve found facilitated meetings to
be useful.
How important is the “group think” that comes from
facilitated meetings? In the elephant story, a revela-
tion comes to the blind men as a wise man affirms their
perceptions and helps them understand each other’s
perspectives. In a facilitated meeting, you help the team
members recognize their unique perspectives, reveal
mutual interests, and distill common agreement. What
makes this process work? In his recent book The Wisdom
of Crowds, James Surowiecki indicates that a successful
group needs a diversity of opinion, independent perspec-
tives, decentralized governance, and a good method for
aggregating opinions. Stakeholders typically arrive at
14
the meeting armed with the first three success factors.
Through facilitation, you enable the fourth.
Facilitation as a tool
Facilitated group meetings generate positive outcomes in
several dimensions. First, consider the axiom, “The whole
is greater than the sum of the parts.” In my experience, a
facilitated meeting routinely generates more high-quality
ideas than would be revealed by one-on-one interviews.
While “designed by committee” is sometimes derided, all
requirements are subject to scrutiny eventually anyway.
There is significant value in distilling and refining the
team’s smorgasbord of requirements early in the project.
Facilitated meetings create value beyond the require-
ments. Even in the first meeting, you will witness the for-
mation of a functioning team. From the ideas suggested
by individual team members, adjustments, clarifications,
compromises, and consensus emerge. Although it may
take three or four meetings, a working team emerges and
produces valuable results.
Building an effective
analysis team
Who should attend the team meetings? At a minimum,
you need the stakeholders or their designees. The team
should also include the project manager, the technical
project manager, and a representative of the sponsor. If
the project is expected to affect numerous business units,
find someone with the experience to plan and execute
communications. The team will also need someone in an
administrative role to take meeting notes and to handle
logistical details. If asked, the project sponsor may sug-
gest a person for this role.
Although the project sponsor may have already set the
team’s membership, you should consider the functional
experience of those who were tapped to participate.
Talk with others who may be affected by the system.
The project sponsor and the current team members are
good resources for the names of others who should be
considered for team membership. Will the membership
adequately represent the functional areas touched by
the new system? Is each team member an expert in a
functional area?
The project manager may be a resource for estimating
the breadth and depth of the team’s experience. He or
she may also know each individual’s work style and work
ethic. If you feel strongly that the team needs more (or
different) resources, make your case with the project
sponsor. Consider asking the sponsor, “Who else could
help this project succeed?”
The facilitation cycle —
setting up
There are three major steps in successfully facilitating a
meeting: setup, execution, and follow-up. Start prepara-
tions by finding a common time and place the team mem-
bers can meet. Check schedules to make sure everyone
has enough time to get to your meeting. Leave some
unscheduled buffer after your meeting as well. This buffer
gives some team members time to linger and ask ques-
tions or discuss an idea. Reserve a convenient, comfort-
able meeting room with adequate table space. Make sure
the room has an adequate supply of flip chart paper and
a stable flip chart stand. You’ll also need two vacant walls
on which you can hang flip chart pages.
As any project manager knows, there is no such thing as
an unwritten plan. This wisdom also applies to meeting
agendas. Write the agenda to include a five- or 10-minute
introduction to the project and use the project charter as
a resource. There may be some new faces among the
team members. Allocate time for brief introductions from
attendees. Although the remainder of the meeting will
be requirements work time, leave five minutes or so at
the end for a “check out” — a chance for participants to
voice an opinion about the meeting or the process. If the
15
expected meeting time exceeds two hours, schedule a
short break in the middle.
When you set a meeting date and an agenda, send an
e-mail to the participants. Copy the project sponsor.
Attach the agenda and project charter. In your message,
set a tone of enthusiasm and excitement. Also, promise
to start and end the meeting on time. Encourage the team
members to come prepared to offer and discuss require-
ments. Indicate you will be calling each person for a brief
chat over the next day or so.
Follow up on your commitment to call. Briefly introduce
yourself and explain the reason you are calling. Ask if they
have a few minutes to talk about the project. If you called
at a bad time, ask them to offer a better time to talk.
Asking about their interests in the project is a good way
to build rapport and keep the phone call short. Take notes
as you listen. Thank them for their time and tell them you
look forward to seeing them at the meeting. Your phone
call reminds them of the meeting and its importance, raises
their interest level, and introduces you in a positive way.
Before the meeting, familiarize yourself with the topic
area. Study the project charter and any supporting
materials. Have a good understanding of the jargon the
team is likely to use. You don’t have to be an expert,
but you have to understand the business concepts and
lingo the team will use. Consider meeting with a
functional expert.
As a final step, gather the materials you need. Find a few
narrow-tip, black felt-tip pens. Make sure they produce
clear lines and don’t bleed through the flip chart paper. If
you don’t have any self-stick flip chart pads, bring along
masking tape for hanging flip chart paper on the meeting
room walls. Bring a few extra ink pens and pencils in case
team members need them.
Execution
Arrive about 10 minutes before the meeting starts.
Arrange chairs around the table to make the attendees
feel comfortable. Hang several sheets of flip chart paper
side by side on one wall. Set up the flip chart pad on the
stand. Have a marking pen handy. Place a few pens and
pencils on the table.
At the beginning of the meeting, ask each person to intro-
duce themselves by giving their name, the business unit
they represent, and their role in the project. During the
introductions, I secretly write for myself a seating chart to
help me connect names to faces.
People improve their focus on a topic when they have had
an introduction to it. Ask the project manager to review
the project charter with the group. Allocate a few minutes
for questions and answers about the project.
Introduce the main section of the agenda by providing
a definition of requirements and their importance to the
project. For the purposes of this meeting, a requirement
can be defined as a feature the new system should have.
If team members seem stuck, you can get them started
by asking, “What are the limitations with the current
system?” On the flip chart pages on the wall, jot down a
key phrase about each limitation and number it. Be care-
ful to write clearly, so that each participant can read and
understand what you wrote. If you feel you misunderstood
what was said, ask the contributor to restate or summa-
rize it while you revise.
As team members run out of suggestions, start them
thinking about the high-level requirements for the new
system. Encourage them to think about people and
process, not technology. As they consider requirements,
the limitations you’ve written on the wall make easy
targets. Even so, new requirements will surface. As you
hear what a team member is saying, think about how to
summarize it. Number each item in the list. Since you
can’t catch every word, write your best summary and ask
the contributor to affirm it or offer corrections. If you got it
completely wrong, strike it and write the correct text. As
you fill up each page, the person filling the administrative
16
assistant role can hang up the pages on an adjacent wall
for all to see.
As the facilitator of this elicitation process, you accept a
mantle of responsibilities and constraints as you chan-
nel the energy, enthusiasm, and ideas of the team into a
workable set of high-level requirements. Strive to enable,
encourage, support, translate, clarify, and record. The
team members provide the content, while you provide a
structured medium to capture and hold it. If a sugges-
tion doesn’t make sense to you, ask the contributor to
clarify it. Encourage participants to expand and reframe
ideas. It helps to smile or nod when someone suggests an
idea. Try to affirm every contributor and thereby raise the
team’s enthusiasm and excitement. Always avoid judg-
ing a contribution. Instead, ask other team members to
wrestle with it through leading questions — “How would
that work in this business unit?” or “What do others think
about that idea?”
Stumbling blocks may arise in the discussion. Help the
team avoid getting lost in a protracted discussion, but
give it time for as long as it bears fruit. If you haven’t
written any new requirements after a few minutes, politely
interrupt the discussion with, “It sounds like we need to
explore this topic in the future. I’m wondering if we can
make a note of that topic and discuss it in depth at a
future meeting.” If the team agrees, write the topic on a
blank sheet of flip chart paper and label it “Parking Lot.”
There is also a chance someone may wander wildly
beyond the scope of project. Acknowledge the importance
of the person’s idea and then ask the group to consider it
in the context of the project mission and goals. If the group
believes it belongs in the Parking Lot, put it there. Promise
to address the Parking Lot items at another meeting.
You may find that time slips away from you during the
meeting. Ask the project manager or the administrative
assistant to help by keeping an eye on the clock. The
team expects you to keep your commitment to end the
meeting on time. By respecting their time, you help team
members develop trust in your leadership. In closing the
facilitation, thank the team for their enthusiasm and ideas.
Tell them that you will type the lists and send them as an
e-mail attachment in the next day or so.
What will you have accomplished? In a few intensive
hours, the team will have defined an impressive (but prob-
ably incomplete) picture of the new system. Don’t worry
that some items on the flip charts are really business
requirements, interface features, or system constraints.
In future sessions, you’ll give the team an opportunity to
clarify, supplement, reframe, and revise these ideas. You
will also introduce them to a place to store each type of
artifact.
Before you close the meeting, invite team members to
briefly “check out” and state any thoughts, ideas, or
concerns about the project or the meeting. Acknowledge
any contributor’s idea and make a note of anything that
should be addressed.
Follow up
Since you scheduled the meeting so that most team
members don’t have to rush out, some may linger in the
meeting room. Often, team members chat and familiar-
ize themselves with each other. While you are gathering
the flip chart pages and restoring the room to its original
state, try to listen to these conversations. You may over-
hear a key point or interesting perspective no one raised
during the meeting.
Consider numbering each flip chart page to record the
sequence in which it was used. Sometimes knowing the
order of ideas is helpful in understanding some detail or
distilling a theme.
I encourage you to type the notes from the flip chart
pages as soon as possible after the meeting. I like to
write two versions. The first one contains the exact words
from the written pages; the other version is a “working”
document that reflects your attempt to clarify cryptic
phrases and to give the reader a better understanding of
the stated requirement.
After carefully proofreading and revising these docu-
ments, enable Track Changes in the working document
and attach them both to an e-mail message you send
to the team. In the e-mail, describe each document
and its purpose. Ask each team member to review the
documents. Encourage team members to add their own
corrections and additions to the working document. Set a
reasonable short-term deadline for their responses.
With Track Changes enabled in the word processor,
suggestions are apparent in the working document they
send back to you. Consolidate these changes with Track
Changes enabled into your own document copy. At the
next meeting, you’ll have the team validate or refute these
suggestions for changes. Eventually, you will lead the
team as they transform these high-level requirements
into business rules, constraints, user interface artifacts,
summary-level use cases, and so on.
Successful projects
This document introduces facilitation as a strategy for
eliciting requirements from a team of people. In facilitated
meetings, the team will accomplished several goals. They
will roughly define how the current system constrains
business success. They will draft a set of requirements
that the new system should satisfy. As a side benefit, the
individual participants will began building an effective
work group, and create forward motion in the require-
ments elicitation process. Each of these achievements
significantly contributes to the success of your project.
17
10 ways to avoid mistakes during
project development
You may have heard the phrase “Be proactive, not reac-
tive.” It’s certainly appropriate when discussing how to
best deal with mistakes. The idea, of course, is to prevent
mistakes before they occur. But how exactly do you do
that?” In this article, I will detail 10 real-world ways you
can preempt mistakes during project development.
4: Follow standards and
use templates
There are good reasons why experienced professionals
took the time to create and publish industry and company
standards. Standards detail best practices and proce-
dures learned over years of trial and error.

For the sake of simplicity, I’ve lumped all errors into one Templates such as predefined forms can be useful since
category: mistakes. The items listed here are specific to most of the work is already done in a standard format. A
developers, but other IT roles can also benefit from many standard EULA approved by your legal counsel is another
of them. good example of a template that can come in handy if you
are developing application software. A mistake in a legal
1: Learn from other’s mistakes
document can be an expensive exercise — one
Find experienced peers who are willing to share their mis-
best avoided.
takes and then learn from them. I am somewhat biased,
but the editors, writers, and members of TechRepublic 5: Communicate and coordinate
seem willing to honestly share their mistakes — even if with others
somewhat embarrassing at times. If you are part of a team, it’s essential to communicate
with other team members to avoid redundancies and to
2: Do your research first
coordinate your work with theirs. Emails, instant mes-
No matter how much you know, you’ll encounter new
sages, project status reports, and teleconferences are all
challenges on an almost daily basis. Each challenge
ways to communicate and coordinate with others on the
usually requires you to learn something new. Before
team. Unfortunately, each of these is far from perfect. You
you tackle a problem or task, do your homework. The
can spend the better part of a day reading and writing
trial-and-error method of learning may have been neces-
emails, participating in conference calls, and instant mes-
sary and acceptable years ago. But with the resources
saging with your peers. But it is a necessary part of the
available on the Internet today, there is little excuse for
development process.
mistakes made because you didn’t do the proper re-
search in advance. The perfect tool for communicating and coordinating with
others in a team environment has yet to be developed.
3: Have a plan
One of the better tools developed to share code is
You can’t know how to get to your destination without a
revision control software. Your project may also benefit
roadmap. In project development, that roadmap is known
from the use of a communication plan that ensures
as a project plan. Whether done formally or informally, you
everyone involved — including customers and stake-
need to know how to get where you are going. Days or
holders — is kept apprised of key developments. (The
even weeks of programming time can be lost if the wrong
TechRepublic downloads library has a free communica-
path is taken. When done the right way, a project plan will
tion plan template to get you started.)
help keep you from straying off course.

18
6: Allow enough time external sources of code are available on the Internet that
can be legally used for free or for a small fee.
It was at Hughes Aircraft Company that I first heard the
phrase “You want it bad - you got it bad.” It didn’t happen
8: Use checklists
very often, but when it did it was almost always made in
Before a commercial plane trip, the pilot and co-pilot are
reference to a part from a vendor that was badly needed,
busy walking through a long, detailed checklist. Check-
rushed through production, and upon arrival, failed
lists can be used during various phases of the project
testing. Failure to allow enough time for each phase of
development process. They are particularly useful when
the project can lead to missed requirements, inadequate
working with large systems and when a single person is
analysis, poor design, rushed programming, insufficient
responsible for multiple tasks.
testing, and incomplete documentation. The result can be
a system that doesn’t meet expectations and fails in one For example, a list detailing the steps required for system

or more key areas.
Estimating the time needed to accomplish each phase of
a project is difficult. I achieved the best results when I sat
down with my supervisor and determined the time allot-
ted for each major task in the project plan. I was overly
turn-on will help avoid accomplishing tasks out of order
and prevent errors of omission. It is all too easy for devel-
opers to overlook important items like system access when
they are busy doing final testing and documentation.
For more on the virtues of using checklists, see Leverage

optimistic in my estimates. He was much more realistic checklists to improve efficiency and client satisfaction.

in his estimates, and he turned out to be right. As a rule

9: Test, test, test… and carefully
of thumb, doubling my initial estimates came close to
review your work
the actual time required. That information was useful for
There is a healthy level of paranoia about delivering error-
developing project plan timelines.
free work. Test as much as possible as early as possible.

You may need to develop a similar rule of thumb until you Errors in the code are typically more expensive to correct

can more accurately estimate completion dates. Ideally, when found near the end of the development process.

you want to complete each phase of the project on time, The last thing you need when facing a critical release date

and the best way to do that is estimate them correctly up is to find a bug that should have been found months ago.

front. Here are a few tips on creating realistic schedules.

Careful and thorough testing will allow you to find those
mistakes before your users can. Double- and triple-check
7: Reuse proven code
your work. Develop test data and a plan to test common
If you’re an experienced developer, you should have
calendar-based events like EOM processing and annual
built up a large code base over the years. Go blue and
reporting. All functionality and every single possible sce-
recycle this code whenever possible. You will likely have
nario should be thoroughly tested. And, yes, this is also a
to modify the code to fit the new requirements, but proven
good place to use a checklist.
core code is a good foundation to build on. Not only will
you reduce the risk of introducing new bugs, but you will
10: Test again with a third party
eliminate the time wasted creating similar code and the
Find at least one experienced person who can be
subsequent testing required.
dedicated to the beta testing. They will undoubtedly use

Share your code with others so they can reuse parts of it. the system in ways you never dreamed of and find bugs

Proven code can be shared via plug-ins or libraries. Good you missed.

19
Don’t overlook or rush this final quality assurance task. It’s
typically your last chance to get it right. Once a bad piece of
software is released or a system with a critical bug is turned
on, a company’s image can be tarnished for years to come.

The final word

One of the most important lessons I learned very early in
my career is that a mistake isn’t a mistake until someone
else knows about it. I was but a young inexperienced pup
when I accidentally deleted some system files on a Tan-
dem PC. It could have been a disaster. But I had enough
sense and problem-solving skills to identify and copy over
the missing files from another Tandem PC.

I have never told anyone until now about my near disas-

ter. This may be obvious, but you should keep unseen
mistakes to yourself. There is almost never anything to be
gained by telling others you have done something really
stupid. It can negatively affect your image and possibly
damage your career.

I hope these proactive tips will help you avoid making an

embarrassing mistake that becomes known to your boss,
peers, and users. If you find yourself in that unenviable
situation, you might want to read Calvin Sun’s article 10
things you should do if you make a big mistake.

I have always learned the most from my mistakes — but I

prefer not making them in the first place.

20
Use a pilot project to confirm estimates
and lessen risks
The dilemma or repetitive. For instance, you may have to implement
that unique solution repetitively in different offices, dif-
I hadn’t talked to Matt since I helped him create an
ferent departments, different Web sites, and so on. With
estimate for converting all our company’s databases to a
proper planning, using a pilot project in such instances
new version. When we caught up recently, he was both
can give you the chance to:
happy and concerned.

Document common procedures that can be

“The estimate we prepared was just what my manager
was looking for,” Matt said. “Fortunately, she has the
budget approval to begin the work, but she said that the
budget is very tight and that we would have to complete
the work within our original estimate.”
utilized on the other similar efforts.
Focus and be successful on one project first,
rather than having to start off with multiple ef-
forts.

I asked when he would begin planning for the project.
“We are just starting the planning now,” Matt replied.
“That’s why I came to see you. I know we put together
a nice estimate based on a model, but it was still just a
model. We haven’t done any conversions yet. If the actual
effort is more than we estimated, we may be substantially
over budget. That could put the entire project in jeopardy.’
The solution
Matt was beginning to see how he should proceed. “I
think the first thing we need to do is validate the esti-
mates,” he said. “What’s the quickest way to do that?”
Reduce the risk of project difficulties since you
can look at what works well and what doesn’t
before tackling the remaining work.
Get a handle on the time and cost required to
complete the entire effort.
In Matt’s case, the pilot project makes great sense
because he has a similar process that needs to be applied
to hundreds of databases. By properly planning the proj-
ect, he can select a representative sample of databases,
transfer this subset of databases to the new release,
document common procedures, and find the average

I noted that the quickest way isn’t always the best way. effort and cost required.

I recommended that Matt conduct a short pilot project.

When the pilot is complete, he can compare the actual
“First, identify a representative sample of databases —
averages with the estimated averages. If the numbers are
large, medium, and small,” I told him. “Migrate them to
not close, Matt will need to notify his manager so that
the new release and keep track of the effort and duration
appropriate actions can be taken before the project gets
for each one. Then you’ll have some factual information
too far along. If the actual migrations are close to the es-
to apply to the estimates — and you’ll know if you should
timates, he can be more confident that the entire project
break out the champagne or the aspirin.”
can be completed within the budget.

Mentor advice
One of the common aspects of software development
is that the solutions tend to be unique. However, you’ll
sometimes find that the work efforts involved are similar

21
Mining project requirements -- techniques to use
before and after an interview
Tom Mochal recently provided excellent tips on interview-
ing techniques to gather project requirements. Conduct-
ing a good interview can be a daunting task -- particularly
if you are interviewing a stakeholder who holds a high
position in the organization, or has a reputation for mak-
ing people uncomfortable. Good preparation and good
follow-up are critical factors in a successful interview.
Prepare for the interview Choose
the right business experts
In the early stages of a project, deciding whom to inter-
view is a challenge. A broad understanding of a business
problem depends on interviewing the people who know
something about it. For that reason, don’t be shy.
Ask the project sponsor for names of the people you
should initially interview. Locate each name in an organi-
zation chart, and consider their title and functional role.
Are there people above and below them in the organiza-
tional hierarchy that you should also interview? Does the
business problem affect vendors or customers? If so, ask
the sponsor for permission to interview representatives
from these groups as well. Be mindful of politics -- the
supervisor of someone you interview may feel jilted if you
decide not to interview them.
Pick the right place
As an interviewer, you have to choose a meeting place that
enables the free flow of information. Unfortunately, there
are many barriers to this flow -- lack of privacy and phone
interruption are examples. If interruptions are a risk, try to
meet outside the person’s office. Consider using a corpo-
rate meeting room, or somewhere offsite. I’ve conducted
some excellent interviews over lunch in a noisy place.
If you must meet in the person’s office, ask that they
“busy” their calls. If privacy is a potential issue, make
22
certain no one can hear through the walls of the room
where you meet. If the interviewee has a packed meeting
schedule or supervises people, convenience or decorum
may dictate a meeting in the interviewee’s office.
Schedule the meeting
Hour-long interviews work well. Recognizing the overhead
of preparation and follow-up, you may think a longer
meeting is best. If you don’t feel an hour is enough time,
set up a second meeting with the interviewee. Enthusiasm
for your questions often fades as the interviewee starts to
think about his or her schedule. When you schedule the
meeting, leave enough time buffers before and after your
interview for the interviewee to travel between meetings.
Leave extra buffer at the end of an interview in case a little
time is needed to finish up.
Prepare yourself
The business problem you are trying to understand has
a domain. Prepare for an interview by learning about that
domain. You should be able to identify the domain inputs
and outputs, and understand the processes within it.
There are many sources for this understanding. Exam-
ine documentation, learn existing systems, or interview
people who can give you an overview of the process.
Early in the project, it helps to create a flowchart or
context diagram showing the entities involved in a system
domain and the nature of their involvement.
Learn the language
As business specializes, jargon develops to identify and
describe its products and processes. In order for you to
understand the interviewee, you have to understand the
language he or she will use. To become familiar with these
terms and concepts, read books that describe the industry.
Your local bookstore or library may have suitable books,
and the Web is increasingly a good source. Consider ask-
Follow-up the interview Review
ing a business expert to recommend a book -- such books
and clarify your notes
are often very valuable. Mentors are probably your most
Good note taking is an important interview skill -- whether
valuable resource for learning to speak the lingo.
you recorded the conversation or not. If you did not

Prepare good questions tape the interview, your notes contain much of what the
interview provided in value. If you did record the interview,
Although you may not use all of them, come prepared
your notes probably summarize key points or identify
to ask good questions. Tom’s article describes “how” to
subject areas to explore further. Either way, review your
interview, but you have to prepare “what” questions to
notes as soon as possible after the interview. Otherwise,
ask. Start by asking yourself:
you may miss important themes or lose clarity on a topic.
What is the project scope? Rely on a project charter to
Ask follow-up questions
provide the context for the questions you should ask.
It is common to have follow-up questions for the inter-
What is the context of the interviewee relative to the
viewee, particularly if you are new to the subject area, or
business need or opportunity you are investigating?
the project is complex. Most people appreciate getting a
Existing operational documentation may provide guid-
follow-up phone call to clarify a few points. When you call,
ance. What am I expecting this person to know? Think
apologize for the interruption and ask if he or she has a
about the interviewee’s role, knowledge, perspectives,
few minutes to answer your follow-up questions. If they
and interests in the context of the project.
are busy, ask for a better time to call. While you can ask
Ask for a second opinion the questions by e-mail, what often ensues is time- con-
When preparing for an interview, write down the questions suming and unsatisfactory.
you intend to ask. It may help you organize and clarify
Summarize your notes and ask
questions. Consider asking a peer to review the
for feedback
questions you plan to ask. Thirty years of interviewing
Ask yourself, “How do I know I understood the stated
people has taught me that there are rarely bad answers
requirements?” Even if you recorded the conversation and
in an interview, but there are plenty of bad questions. By
listened to the tape, the interviewee may have intended
having someone else review your questions, you may
something other than what was said. In addition, the
discover a perspective on the interview you hadn’t con-
answers to your questions may have only uncovered a
sidered. A second pair of eyes may also help you root out
portion of the requirement you hope to define. Summarize
improper questions. A peer’s suggestions may add great
each of the requirements you heard. Send the interviewee
value to questions you plan to ask.
an e-mail with the requirements as an attachment. Be
Consider recording the interview sure to thank them for their time and interest in the

If you have only one opportunity to interview someone, project. Invite them to review what you wrote and ask

bring along a tape recorder. Travel distance, difficult sched- them to contact you to correct the requirements.

ules, or organizational statuses are sometimes barriers to

Next steps
conducting a follow-up interview. Be sure to ask permis-
While preparing adequately for a requirements interview
sion from the interviewee before you begin recording. Be
does not guarantee success, failing to prepare puts your
honest and indicate why you need to record the interview.
interview at risk. Adequate interview follow-up improves
Plainly indicate the tape will not be shared with others.
the quality of the requirements you uncover.

23
Use prototyping to visualize
project requirements
A prototype represents the shell of an actual production
application. Prototypes are built early in the development
lifecycle, and they’re used to provide valuable insight into
the look, feel, and general workflow of an application.
(Sometimes people call the first production implemen-
tation a prototype, but that’s not correct. If you have
multiple implementations, the first one is more aptly called
a pilot test. Likewise, a prototype is not used to validate
whether a proposed solution works. This is more aptly
called a proof-of-concept.)
The main purpose of a prototype is to gather and docu-
ment requirements. If you’re pretty confident that you
have a good set of requirements, there’s not necessar-
ily a reason to build an initial prototype. After you build
an initial prototype you should show it to the clients to
validate the work done so far looks okay. You then use
the prototype to gather additional requirements. As you
receive requirements, you should document them in the
same way you would document the additional require-
ments you’re gathering though other means.
The prototype starts off as a shell that contains the online
screens. There should be very little programming of the
core business processes and only enough program code
to allow the prototype to go from screen to screen. The
point of the prototype is to provide a visual representation
of the application, not the complex business logic that
goes behind it.
What happens to the prototype?
There are two options for what happens to the prototype
once it’s built.
Complete or partial throw-away. Typically, if
you build a prototype, you’ll throw it away after
the requirements have been gathered. Remem-
ber that the prototype does not have to be the
24
start of the final solution. The main purpose is
to gather requirements. I’ve seen online applica-
tions that appeared to be running on the web,
when, in reality, the team members built the
prototype in PowerPoint or Excel. There was no
thought that somehow this PowerPoint prototype
would be reused further as the project progress-
es. On the other hand, in many instances you’ll
build a prototype using the same technology as
the final solution. In this case, there may be some
aspects that can be reused. You may be able to
leverage some of the physical components of the
prototype as a starting point for the Design and
Construct Phases of the project.
Iteratively develop into final application. If
you’re using an iterative development approach,
the first prototype should still be put together
quickly. However, instead of the work being
abandoned or thrown away, the prototype is up-
dated with the new requirements. In the second
pass, more business logic is also placed into the
application. At this point, it’s no longer called a
prototype. Instead, the prototype shell is used as
the basis for developing the final solution.
In summary, prototypes are used to gather requirements,
and are especially useful in visualizing the look and feel of
an application and the process workflow. The useful life
of a prototype will vary according to the project lifecycle
model. It’s possible that the prototype can be thrown
away, or that some components can be reused later in the
project. It’s also possible that the prototype can be used
as the basis for developing the final solution.
10 best practices for successful
project management
Given the high rate of project failures, you might think
that companies would be happy to just have their project
finish with some degree of success. That’s not the case.
Despite the odds, organizations expect projects to be
completed faster, cheaper, and better. The only way that
these objectives can be met is through the use of effec-
tive project management processes and techniques. This
list outlines the major phases of managing a project and
discusses key steps for each one.
Planning
1: Plan the work by utilizing a proj-
ect definition document
There is a tendency for IT infrastructure projects to
shortchange the planning process, with an emphasis on
jumping right in and beginning the work. This is a mistake.
The time spent properly planning the project will result
in reduced cost and duration and increased quality over
the life of the project. The project definition is the primary
deliverable from the planning process and describes all
aspects of the project at a high level. Once approved by
the customer and relevant stakeholders, it becomes the
basis for the work to be performed. For example, in plan-
ning an Exchange migration, the project definition should
include the following:
Project overview: Why is the Exchange migration
taking place? What are the business drivers?
What are the business benefits?
Objectives: What will be accomplished by the
migration? What do you hope to achieve?
Scope: What features of Exchange will be imple-
mented? Which departments will be converted?
What is specifically out of scope?
Assumptions and risks: What events are you tak-
ing for granted (assumptions), and what events
are you concerned about? Will the right hard-
ware and infrastructure be in place? Do you have
enough storage and network capacity?
Approach: How will the migration project unfold
and proceed?
Organization: Show the significant roles on the
project. Identifying the project manager is easy,
but who is the sponsor? It might be the CIO for a
project like this. Who is on the project team? Are
any of the stakeholders represented?
Signature page: Ask the sponsor and key stake-
holders to approve this document, signifying that
they agree on what is planned.
Initial effort, cost, and duration estimates: These should
start as best-guess estimates and then be revised, if
necessary, when the workplan is completed.
Project Workplan
2: Create a planning horizon
After the project definition has been prepared, the
workplan can be created. The workplan provides the
step-by-step instructions for constructing project deliv-
erables and managing the project. You should use a prior
workplan from a similar project as a model, if one exists.
If not, build one the old-fashioned way by utilizing a work-
breakdown structure and network diagram.
Create a detailed workplan, including assigning resources
and estimating the work as far out as you feel comfort-
able. This is your planning horizon. Past the planning
horizon, lay out the project at a higher level, reflecting the
increased level of uncertainty. The planning horizon will
25
move forward as the project progresses. High-level
activities that were initially vague need to be defined in
more detail as their timeframe gets closer.
Project Management
Procedures
3: Define project management pro-
cedures up front
The project management procedures outline the re-
sources that will be used to manage the project. This will
include sections on how the team will manage issues,
scope change, risk, quality, communication, and so on. It
is important to be able to manage the project rigorously
and proactively and to ensure that the project team and
all stakeholders have a common understanding of how
the project will be managed. If common procedures have
5: Look for warning signs
already been established for your organization, utilize
Look for signs that the project may be in trouble. These
them on your project.
could include the following:
4: Manage the workplan and moni-
tor the schedule and budget
Once the project has been planned sufficiently, execution
of the work can begin. In theory, since you already have
agreement on your project definition and since your work-
plan and project management procedures are in place,
the only challenge is to execute your plans and processes
correctly. Of course, no project ever proceeds entirely as
it was estimated and planned. The challenge is having the
rigor and discipline needed to apply your project manage-
ment skills correctly and proactively.
Review the workplan on a regular basis to
determine how you are progressing in terms of
schedule and budget. If your project is small, this
may need to be weekly. For larger projects, the
frequency might be every two weeks.
Identify activities that have been completed
during the previous time period and update the
workplan to show they are finished. Determine
whether there are any other activities that should
be completed but have not been. After the
26
workplan has been updated, determine whether
the project will be completed within the original
effort, cost, and duration. If not, determine the
critical path and look for ways to accelerate
these activities to get you back on track.
Monitor the budget. Look at the amount of
money your project has actually consumed and
determine whether your actual spending is more
than originally estimated based on the work that
has been completed. If so, be proactive. Either
work with the team to determine how the remain-
ing work will be completed to hit your original
budget or else raise a risk that you may exceed
your allocated budget.
A small variance in schedule or budget starts to
get bigger, especially early in the project. There is
a tendency to think you can make it up, but this
is a warning. If the tendencies are not corrected
quickly, the impact will be unrecoverable.
You discover that activities you think have al-
ready been completed are still being worked on.
For example, users whom you think have been
migrated to a new platform are still not.
You need to rely on unscheduled overtime to hit
the deadlines, especially early in the project.
Team morale starts to decline.
Deliverable quality or service quality starts to
deteriorate. For instance, users start to complain
that their converted e-mail folders are not
working correctly.
Quality-control steps, testing activities, and
project management time starts to be cut back
from the original schedule. A big project, such as
 an Exchange migration, can affect everyone in
your organization. Don’t cut back on the activi-
ties that ensure the work is done correctly.
If these situations occur, raise visibility through risk man-
agement, and put together a plan to proactively ensure
that the project stays on track. If you cannot successfully
manage through the problems, raise an issue.
Managing Scope
6: Ensure that the sponsor approves
scope-change requests
After the basics of managing the schedule, managing
scope is the most important activity required to control a
project. Many project failures are not caused by problems
with estimating or team skill sets but by the project team
working on major and minor deliverables that were not part
of the original project definition or business requirements.
Even if you have good scope-management procedures
in place, there are still two major areas of scope-change
management that must be understood to be successful:
understanding who the customer is and scope creep.
In general, the project sponsor is the person funding the
project. For infrastructure projects like an Exchange mi-
gration, the sponsor might be the CIO or CFO. Although
there is usually just one sponsor, a big project can have
many stakeholders, or people who are impacted by the
project. Requests for scope changes will most often come
from stakeholders — many of whom may be managers in
their own right. One manager might want chat services for
his or her area. Another might want an exception to the
size limits you have placed on mailboxes. It doesn’t mat-
ter how important a change is to a stakeholder, they can’t
make scope-change decisions, and they can’t give your
team the approval to make the change. In proper scope-
change management, the sponsor (or a designate) must
give the approval, since they are the only ones who can
add funding to cover the changes and know if the project
impact is acceptable.
7: Guard against scope creep
Most project managers know to invoke scope-change
management procedures if they are asked to add a major
new function or a major new deliverable to their
project. However, sometimes the project manager doesn’t
recognize the small scope changes that get added over
time. Scope creep is a term used to define a series of
small scope changes that are made to the project without
scope-change management procedures being used. With
scope creep, a series of small changes — none of which
appear to affect the project individually — can accumulate
and have a significant overall impact on the project. Many
projects fail because of scope creep, and the project
manager needs to be diligent in guarding against it.
Managing Risk
8: Identify risks up front
When the planning work is occurring, the project team
should identify all known risks. For each risk, they should
also determine the probability that the risk event will
occur and the potential impact on the project. Those
events identified as high-risk should have specific plans
put into place to mitigate them so they do not, in fact,
occur. Medium risks should be evaluated to see whether
they need to be proactively managed. (Low-level risks
may be identified as assumptions. That is, there is
potential risk involved, but you are “assuming” that the
positive outcome is much more probable.) Some risks are
inherent in a complex project that affects every person in
the company. Other risks may include not having the right
level of expertise, unfamiliarity with the technology, and
problems integrating smoothly with existing products or
equipment.
9: Continue to assess potential risks
throughout the project
Once the project begins, periodically perform an updated
risk assessment to determine whether other risks have
surfaced that need to be managed.
27
10: Resolve issues as quickly as
possible
Issues are big problems. For instance, in an Exchange
migration, the Exchange servers you ordered aren’t ready
and configured on time. Or perhaps the Windows
forest isn’t set up correctly and needs to be redesigned.
The project manager should manage open issues
diligently to ensure that they are being resolved. If there
is no urgency to resolve the issue or if the issue has been
active for some time, it may not really be an issue. It may
be a potential problem (risk), or it may be an action item
that needs to be resolved at some later point. Real issues,
by their nature, must be resolved with a sense of urgency.

28
JAD sessions will speed up the
project definition process
Question
The last time I managed a project, it seemed like it took
forever to get all of the major stakeholders to agree on
what we were doing. The process of gaining approval
obviously had value since there were some major differ-
ences of opinion on what the project was to accomplish.
However, the time required to get everyone’s acceptance
was unacceptable.
I have subsequently read about a JAD technique that
might help us get through this process faster. What can
you tell me about it, and is it something that can be used
on a project?
Answer
You’re right. There is a specific technique (or set of tech-
niques) for more rapidly gaining a consensus from a group
of individuals. The technique is called joint application de-
velopment, or JAD. Judging by its name, you might think
that this technique only applies to developing software,
but that’s not the case. Although I don’t know the origin
of the term, the JAD technique can be applied to a wide
variety of areas where consensus is needed. This includes
gathering business requirements, creating a project work
plan, building a quality management plan, and so on. In
particular, based on your question, the technique can be
applied to help define a project.
The normal way
Let’s briefly recap how you normally define a project. First,
you might talk to your manager and the project sponsor.
They give you enough information so that you can start
to talk to other interested stakeholders. You begin to
write a project definition and realize you don’t have all the
information you need, so you make a second round of
talking to people to ask clarifying questions. You create
a draft project definition that is circulated back to these
stakeholders. Many of them read the document and say
fine, but some will have questions, or they may disagree
with some of the content. The disagreements must be
taken back to the sponsor for resolution, and perhaps an-
other round of discussions takes place to provide further
clarification and to build a consensus.
Depending on how controversial the project is, you may
get a consensus on the project definition quickly, or it may
take quite a long time. It appears, from your question, that
you have already become familiar with the “quite a long
time” process.
Enter the JAD session
The purpose of the JAD session is to dramatically reduce
the timeframe required to complete a deliverable where
consensus is required. Notice that I did not say it would
dramatically reduce the cost. Depending on how the JAD
is implemented, it may, in fact, cost more than the tradi-
tional methods. However, in many cases, your manage-
ment and sponsor are willing to pay more for a process
that takes much less time.
How dramatic could the time savings be? Very dramatic.
As an example, the time required to produce the project
definition might be reduced from six weeks to one week,
or perhaps even two days. So, this is not about reducing
turnaround time by 10 percent. JAD sessions can result in
dramatic improvements—maybe 75 percent, 80 percent,
90 percent, or higher.
The JAD process
The key concept of a JAD session is that you get all of the
major decision makers, stakeholders, and knowledge pro-
viders into one place all at the same time. The dramatic
reduction in time comes from removing the time required
to move information from person to person. If a stake-
holder has a question about scope, he or she can ask it
29
in the context of the JAD session. The people required to
answer the question are in the room and can answer the
question immediately—there is no time delay and no mis-
representing the question. A two-week process of getting
a question clarified and answered can instead take place
in 10 minutes, because all of the right people are there at
the same time.
The JAD session
The concept of the JAD session implies more than just
getting everyone together for a day to discuss all the
issues. There is usually a set of formal techniques that are
applied to these sessions to make them as productive as
possible. These include:
Identifying the right people and making sure
they are there. It’s fine to invite the project
sponsor and the major clients and project team
members. But what questions might arise that
require others to be there as well? All decision
makers must be present, as well as information
providers. The information providers can be on-
call if needed so that they do not have to attend
the entire session. If you hold a JAD session and
none of the participants can make decisions or
the people with information are not available, it’s
not going to be successful.
Using a facilitator(s). Normally, a formal JAD
session has a formal facilitator (a trained facilita-
tor, if possible). The facilitator makes sure the
discussion stays on track, that meeting rules are
followed, and that the meeting is as productive
as possible.
Having someone take notes. There needs to be
someone taking notes, documenting decisions,
and noting any action items. If there are cofacili-
tators at the meeting, the second person can be
the scribe.
30
Spending the time necessary to reach
conclusion and consensus. This is important:
The objective of the JAD session is to go through
all of the items that need to be discussed and
reach a consensus on what needs to be done.
If this requires a one-day session, then all of the
participants must make a full-day commitment. If
this requires everyone to get together for a week,
that is the commitment that needs to be made.
Case study
I used JAD techniques on a project to implement project
management processes at a Fortune 500 company. In our
case, we used the session to gain a consensus on the cur-
rent state of project management in the organization. Since
this was a worldwide project, it would normally have taken
us at least a month to get with all the key players around
the world, gather their feedback, and gain agreement on a
document that described the current environment. Instead,
we identified the right group of people and brought them all
to our headquarters for a three-day JAD session.
These people came from around the world. It was prob-
ably more expensive to use the JAD approach, but the
final deliverable was completed and approved in three
days, instead of the 30 or more days under a traditional
approach. We also felt like it was of higher quality, since
the contributors were all talking face-to-face.
A JAD session might be just what you need if it would take
you a long time to reach consensus on your project defini-
tion under normal circumstances. The sponsor must work
with you to identify the right people and make sure that
they will all make the time commitment necessary (includ-
ing the sponsor). Get yourself a facilitator and a scribe and
get everyone together to hammer out and agree on the
details of your project. You should be able to complete the
project definition immediately after the session, or even
during the session, and have everyone approve the final
document very soon after the JAD session is over.
Don’t fall prey to these false
project requirements
In project management, requirements describe how a spending too much money on the project, he’s
product or service should act, appear, or perform. These offering an opinion — not a requirement.
details explain the features and functions of the products
Project-related statements: Requirements
or deliverables the project needs to have.
describe deliverables — not the project. For
If you could ask your clients about requirements and example, if a client tells you that “we should
know they were responding with exactly everything they prototype this solution first,” he’s giving you
needed, gathering requirements would be a piece of cake. input for the project approach — not a require-
However, in the course of the requirements-gathering ment. If a client states that she wants the project
process, it just usually isn’t that easy. completed by a certain date, she’s giving you a
schedule constraint — not a requirement.
In fact, you’ll often hear information from clients that, on
the surface, appear to be requirements when they actu- Comments from the wrong person: It’s important
ally aren’t requirements at all. We call these items false to know the role of a person providing require-
requirements. ments, so you can determine if the information
he’s providing is consistent with his authority. For
False requirements come in many forms. Here are some
example, a user might tell you, “I think we
of the more prevalent categories:
should allow our vendors access to this
Vague requirements: How many times does a information.” This isn’t a requirement since the
client offer a statement that contains a hint of typical user doesn’t have the power to make this
one or more requirements but doesn’t offer any type of decision.
kind of specifics? Vague requirements require
Unrealistic or not testable: You might hear
good follow-up and probing questions to make
requirements that are really just marketing hype
sure you have the correct level of detail. For
or extreme hyperbole. For instance, a client man-
instance, your sponsor might tell you, “I want
ager may tell you, “This product needs to be able
this application to make employees’ lives easier.”
to run on the moon.” This isn’t a real requirement
This is not specific enough to be a requirement.
since you can’t test or validate it. Make sure to
You need to ask some follow-up questions to
ask follow-up questions to determine the real
learn exactly how the client wants the application
requirements behind the statement.
to help employees.
Learning how to quickly recognize these false requirements
Opinions: While opinion statements can be
and how to dig deeper for the details is vital for a project
requirements, many times they’re not. In many
manager. It can help save time in reworking the project as
cases, the client will provide an opinion on the
well as prevent further confusion later in the project4
features and functions of a deliverable, and
these are valid statements. However, if a client
manager tells you that he thinks the company is

31
10 ways to avoid stupid project estimates
Projects run on estimates. You either have to provide
3: Challenge the numbers
estimates of things such as how much effort your task
Push back. Ask questions. Project managers seem to do
will require or you will need such information from others.
this pretty naturally, but challenge the developer or devel-
Unless you’re in one of a small handful of roles, you will
opment team to explain why they think it will take so long.
surely come to rely on estimates of others, even if it’s
If they can justify their estimate, at least you will know
just to frame your own estimates. And if you’re a project
that they gave it some thought. If they can’t, perhaps they
manager, the estimates of others are probably all you
should be thinking about their estimate some more before
have to work with.
you start relying on their figures. Don’t be surprised if the

Overall, project estimates are only as good as the indi- estimate actually goes up. It would not be the first time

vidual estimates associated with the component tasks. As I’ve seen a discussion with developers expose previously

much discussion as there is on the estimation process, undiscovered project tasks. While not great news, it’s

there isn’t a great deal of information on getting better still better to find out about this sooner rather than later.

estimates from others. Here are a few ideas to help you Left hidden, those tasks would have surely destroyed the

see this aspect of estimating more clearly -- and help you timeline when they came to the surface and jumped onto

avoid leading your project astray before it ever starts. the critical path.

Vetting the estimates 4: Measure

Okay, you know your developers are always missing their
you get today
estimates, but by how much? If you aren’t measuring it,
1: Let history be your guide
you really don’t know whether you have a big problem
It is true: History does repeat itself. I can’t tell you the
-- or maybe don’t have a problem at all. This also ties into
number of times I’ve seen developers give an estimate
the history suggestion above. How long does it usually
oftwo days and actually take four. There’s nothing wrong
take? You don’t know unless you track this information.
with that, because there was probably four days’ worth
Metrics also go a long way toward improving estimates.
ofwork to begin with. The problem is that I also see
Like any process, you can’t improve it if you don’t mea-
people in meetings repeatedly believing them. If it has
sure it. Unfortunately, a deep dive into this topic would
taken twice as long as the estimate the last five times an
be an entire article (or two) in itself. But if you don’t have
estimate was given, why would anyone think the estimate
a clue where to start, just start capturing expected date
will hit this time? Beats me, but some people continue to
versus actual delivery date. You might be surprised by the
fall for it. Unlike the stock market, past performance can
patterns that develop.
be an indicator of the future.
5: Bracket the work
2: Ask for details (proof)
This is for those who just can’t come up with a time
Learn the justification for an estimate. If you ask why they
estimate for the work. First, try helping them break down
think it will take two days, and you get a reasonable
their work into smaller, more manageable, tasks. Next,
task-by-task break down of the two days’ work, two days
you may find it useful to use a simple bracketing tech-
may be right on the mark. But if your developers just
nique to help the person zero in on the figure that is
shrug their shoulders, it may be time to worry. This also
appropriate. “Is five days enough time?” “Can you do it in
provides a great opportunity to assess their assumptions.

32
less than 10?” Continue in this fashion until you get a figure
that everyone is comfortable with. Of course, you should be
challenging and asking for details throughout this process.
6: Get a second opinion
When you’re hiring a builder, they say you should get
several estimates, throw out the highest and the lowest,
and then go with the one in the middle. There might be
something to that approach. When working with a team,
you’re probably getting your estimates from the team’s
point person -- a lead developer, for example. While this
is efficient, it may add some risk to the accuracy of any
estimate you receive, especially if there is a wide variance
in the estimates of the individual team members. You
may be getting the result of a faulty team consensus, a
blatant falsehood to avoid having to face some
development reality, or an estimate flawed by an innocent
miscommunication.
If you have reason to suspect an estimate may be off, or
if the team has a bad track record for this sort of thing,
a second opinion may be in order. Seek an informal read
from other members of the team. If you run the team
estimate past an individual developer, and he wrinkles
his nose at it, you may have some more digging to do. If
everyone is of a like mind, you probably have as good a
number as you can expect.
7: Remember that two heads are
better than one
Run your figures past someone who might have experi-
ence with your type of project. If this person is not on your
project, all the better. Perhaps you’re a sucker for good
news. Perhaps they are telling you what you want to hear.
An objective third party is exactly what you need to free
you of your bias and give you a clearer view of reality.
Improving future estimates
8: Give feedback
You have captured task estimates, and you have tracked
actual. From this, you may have learned that certain
groups always underestimate by 25 percent. That is
certainly good to know, but don’t let the value stop there.
Provide feedback to the team members. Help them
identify patterns in how they estimate and challenge them
to find the root cause of their bad estimates. Generally
speaking, people really do want to do a good job, so
provide them the tools and a few suggestions. Your folks
will be able to take it from there.
9: Reward and penalize
Penalize the bad estimate, not that a task estimate is
too long. When estimates are shortened, it’s generally
because that shorter number is what’s expected. That is
where the “If all goes well, it will take...” comes from. Be
serious. When was the last time “all went well”? There’s
nothing wrong with qualifying an estimate, but adding an
unrealistic assumption as a way to give a bad estimate
only hurts the project. You want to drive toward behaviors
that give better estimates. Celebrate when estimates
are hit. When estimates are missed, you don’t need to
tar and feather the offenders, but you can treat it as a
remedial education opportunity (the very act of which will
be a penalty of sorts). Be careful about rewarding beat-
ing an estimate differently from hitting it. If you create the
situation where it is better to beat an estimate than simply
meet it, you will create an incentive for overestimating.
10: Develop a culture
Using the correct rewards and penalties goes a long
way toward establishing the right culture, but what is the
right culture? Certainly, it’s one in which those providing
estimates feel safe in providing accurate information as
opposed to providing the information they believe super-
visors want to hear. However, it must also be one in which
everyone strives to improve the quality of their estimates
and the notion of providing a bad estimate is as bad as
providing bad program code. Managers must also respect
those providing them with information, once those people
have proven themselves. Ultimately, if you can get peer
pressure to “manage” the estimates, your job will become
considerably easier.
33
Improve your project... one
estimate at a time
You can’t run a project well with bad estimates, any more
than you can build a house with faulty bricks or lumber.
Fortunately, you don’t need to do everything yourself
(nor could you) to get estimates you can trust. Exercis-
ing the simple ideas above will help you filter out the bad
numbers you get today, improve the numbers you get
tomorrow, and generally make your life a whole lot better
-- at least as far as your project is concerned.

34
10 ways to overcome resistance to
project collaboration software
Since the emergence of Web (insert arbitrary number
here).0—with social networks, bookmarking, online
applications, photo tagging, and blogs—collaboration has
become the dominant characteristic in the way we work,
live, and play. To a large extent, software as a service
(SaaS) has made this phenomenon possible, eliminating
the need to buy, distribute, install, and learn conventional
software.
According to a report by THINKstrategies and the Cutter
Consortium, more than a third of small and large busi-
nesses will adopt SaaS into their technology portfolio dur-
ing the next year to help bolster such activities as project
management and internal collaboration. About 80 percent
of those considering it say they plan to adopt it within the
next 12 months.
Unfortunately, some project managers who may other-
wise eagerly share vacation photos with family members
through Flickr or freely respond to a blog posting remain
reluctant to adopt project collaboration software. They
have become bogged down in paper-based systems
or standalone software and have not yet realized the
benefits of turning to a networked environment for their
crucial work projects. Yet the success of implementing
a software-based project collaboration system depends
wholly on the willingness of potential users to integrate
the system into their work flow and work habits.
To help avoid such resistance, businesses should con-
sider 10 practical steps that can enable the company to
gain the support of its staff and the efficiencies inherent in
project collaboration software.
1: Start with the basics—
incorporate everyday tools
Choose software with familiar, everyday tools, such as
e-mail integration, Wikis, and instant chat. This makes intro-
ducing new software less intimidating right from the start.
2: Novel concept alert:
Ask the user first
Consult the people who will actually be using the software
before making a purchase. Take it from the experts: “IT
professionals, project managers, and business devel-
opment managers should provide input into the PPM
[project and portfolio management] investment decision;
otherwise, the tool might not be capable of providing all
promised benefits.” —Daniel B. Stang, Gartner research
3: Loosen up—go
subscription-based
Subscription-based pricing is more flexible, so you can
deploy on a small scale first to make sure it is right for
your company. Pay-as-you go flexibility allows organiza-
tions to add or subtract functionality as needed, so you’re
not locked into expensive commitments.
4: Collaboration promotes
adoption
Tools that offer enhanced collaboration abilities lead
to more rapid adoption, as teams can grow virally and
expand as more employees are pulled in.
5: The key word is “user”
interface
Remember that it’s a user interface, not a developer
interface—navigating the system shouldn’t be like solving
a Rubik’s cube or completing a scavenger hunt. Rather, it
should be brilliant in its simplicity. Choose software with
a friendly, intuitive interface designed with the end user in
mind, and people will be more willing to give it a try.
6: Fast deployment = fast
adoption
Common sense tells us the quicker a solution is de-
ployed and is up and running, the quicker employees
can familiarize themselves with it. This means selecting
software—most likely SaaS—that doesn’t require an IT
35
SWAT team of installers or hours-long training sessions.
Venture capitalists are noticing this trend: “What we see
now is a huge increase and adoption of Web apps that
are equivalents of business or consumer apps that you
used to install on your PC or Macintosh,” said Jeff Clavier,
managing partner of SoftTech VC.

7: Adoption flows downhill

Lead by example. If others see team leaders using the
software, they will be motivated to follow suit.

8: Less is more
Make sure to distinguish between “must have” and “nice
to have.” Inundating your team with a solution that has
all the bells and whistles will intimidate and veer users
away from a smooth adoption. Apply the 80%-20% rule.
It works!

9: It takes a village community

Offer a help community—quick, anonymous online assis-
tance forums for troubleshooting and shared experiences.

10: Offer cash rewards

When all else fails, bribe employees with cash and/or
fabulous prizes.

36
Categorize high-level requirements into use case
titles for better project management
Many business analysts use Unified Modeling Language
use case diagrams to identify the actors and their high-
level actions in a system. These diagrams help an analysis
team clarify and understand the project domain and high-
level functions. Unfortunately, UML use cases fail to tell
us much about the details of a system. They define “who”
and “what” pretty well, but don’t tell us “when,” “where,”
“why,” and “how.” Learn how to transform high-level
requirements into a set of story titles that can be applied
toward functional requirements.
Importance of stories
Recognizing the importance of UML to a business ana-
lyst, you may wonder why stories are also important. In
a broad sense, stories help us make sense of ourselves,
each other, and our world. Think about the last movie you
saw, or a book you read. If the story was told well, there is
a good chance you can retell it. You probably remember
when a critical event occurred, along with the sequence
of events, and who was involved. Through the story, you
also understood a participant’s motivations, perspectives,
and behaviors.
It may not be a surprise to hear that story writing is a very
powerful tool for the business analyst. In this article, we
learn how to transform high-level requirements into a set
of story titles. Future articles in this series will describe how
to evolve these titles into clear, succinct, and comprehensive
narratives about a business process. Written in a language
both functional staff and technical staff can understand,
each detail-level use case narrative is a story that answers
the “who, “”what,” “when,” “where,” “why,” and “how” of
a business process. Collectively, these narratives speak
volumes about a system and its functional requirements.
Starting from a foundation
We began the process of writing use case narratives
by helping the analysis team define high-level system
requirements. If you followed that process, you have
a good foundation for defining the system’s functional
requirements. Whether you have 50 or 500 high-level
requirements, you can now help the team organize them
into manageable chunks.
As a product of your work with the team, let’s assume
you now have a rough set of high-level requirements in an
electronic document. Before meeting with the team, give
members an opportunity to review the high-level require-
ments and fill some holes. It will simplify communication
during the meeting if you number each high-level require-
ment in the electronic document before sending it to
the team. Ask each person to come to the next meeting
prepared to improve on the requirements. Send along
an agenda for that meeting containing two work tasks:
“Clarify Requirements” and “Organize Requirements.”
Before the meeting, copy the requirements text into a new
document and arrange three or four requirements on each
printed page. Increase the font size to allow easy reading
from about four feet. Print the document and cut up the
pages so each requirement appears on its own piece of
paper. You should end up with a set of readable 8-1/2 by
roughly 3 inch strips of paper, each one with a
requirement on it.
Let’s call these slips of paper the “requirement notes.” It
is a good idea to make a second set of these notes as a
duplicate. To complete your preparations, also bring to
the meeting the usual materials: a flip chart pad, masking
tape, and several narrow-tip marking pens. Bring along
some half-sheets of letter-size paper on which to write
new high-level requirements. Just before the meeting
begins, hang flip chart pages side by side on a wall.
You’ll need enough flip chart pages to hold the high-level
requirement notes comfortably — figure roughly eight
notes per flip chart.
37
Clarify the requirements
Start the meeting by introducing the team to what they will
be doing. Briefly explain the purpose of the flip chart pages
on the wall and talk about the set of requirement notes.
Begin work on this first agenda item by spreading the
requirement notes out on a large table. Give team members
time to stand up and review their previous work. Encour-
age members to take a marker and amend the requirement
notes. Ask them to use the half-sheets of blank paper to
record any new requirements theydiscover.
The team’s first activity shouldn’t take more than 10
minutes or so. You can measure the completeness of their
work by checking for inactivity among the group. Be silent
as they work. An ancient proverb comes to mind — “A
word is worth one gold coin; silence is worth two.” Leave
the group standing for a minute and let them survey the
set of requirements one more time.
Organize the requirements
Now you may introduce the second agenda item to the
group. Explain that you would like them to arrange the
requirement notes on the wall. Have plenty of strips of
masking tape ready for affixing the notes to the flip chart
pages you hung earlier. Ask them to group the require-
ment notes that seem to fit with one another onto the
same flip chart page. Tell them that there is a duplicate
set of the requirement notes available if someone finds a
requirement that belongs on two pages. Encourage them
to talk as they work, and to rearrange the notes as they
see fit. Again, be patient. Give people time to organize
their thoughts.
When the work seems done, have them take a short
break and ask that they return in five minutes. While they
are away, read the flip chart pages. When team members
return and are ready to begin, ask them to reevaluate the
requirement notes posted on the flip chart pages. Assign
one or two volunteers to a single flip chart page. Ask each
sub-team to evaluate its assigned page. Do the require-
ment notes seem well organized? Do all of the notes
38
seem appropriate for the page? Should a new require-
ment be added to the page?
Give the sub-teams about 10 minutes to complete their
work. When the whole team seems ready, have each sub-
team summarize its flip chart page to the whole group.
Team members are likely to hear a well organized feature
set for the system categorized by sub-system. As a final
exercise, have the team spend a few minutes examining
the whole set of flip chart pages and adjust or add notes
as they see fit.
This meeting will probably require about two hours. At the
end, spend a few minutes describing how you will use
their work. Indicate you will group the requirement notes
and develop use case titles for them. Explain that a use
case title describes an actor in the system doing
something. A title is a simple declarative statement in the
form “actor-verb-object.” If I were describing my com-
mute to work as use case titles, I would include “driver
starts the car,” “driver picks up carpool rider,” and “driver
drives to work.” Based upon your own review during the
team’s break, you can probably suggest meaningful titles
to the group.
Next steps
The deliverable for this meeting is something I’ll call a use
case catalog. Create an electronic document that con-
tains a table with two columns. In the left-hand column,
write a use case title that describes a group of require-
ment notes from a flip chart page. In the adjacent right-
hand column, copy and paste the electronic requirement
notes that fit under the title’s umbrella. (Since tracing
the origin of a requirement is important, carry along the
number assigned to the requirement as well.)
For example, if the requirement notes described the
features of a new accounting system, we might have use
case titles such as “Clerk sets up a new account” and
“Supervisor overrides an accounts payable exception.”
As you develop this document, you will notice that some
of the requirements seem like process-oriented steps.
Others seem like business rules or constraints. Some
requirements may not fit at all. If you can’t find a home
for a requirement, be honest about it. Place it in a row in
which the use case title is simply “Unknown.”

Lesson learned
Following a core principle makes this whole process
successful. Remember that while you own the process
that the team is using, they own the requirements. While a
home may be found for the orphan requirement, the team
is best suited to find it. They may decide it is not really a
requirement, or they may add another half-dozen require-
ments they hadn’t considered. You must show them the
path to producing good requirements, encourage them to
explore what they require of the system, and advise them
to make good decisions along the way. Let the tension
inherent in early, fuzzy requirements drive them to create
clarity. Despite imperfections, or because of them, send
the newly drafted use case catalog to the team.

39
A four-step prescription for writing
better project plans
A long time ago, in a lifetime far far away, a client asked ect. A project plan written to aid executive reporting might
me to help their PMO produce useful project plans. Never not contain the information an auditor wants, just as one
one to turn away a job, I agreed to speak with him and written to help the project manager actually track multiple
review the documents his team produced. Leafing though interwoven sites will read differently than any of the above.
the packet, I found the same things I always find in project
Trying to write a project plan to cover all “whats” gener-
plans - lack of coherent planning, no focus on document
ally leaves the author with a confused, useless mess. Not
purpose, and a very limited control of how tasks interact
unlike what I find in organizations all over the country.
to create workable processes.

2: Who will use this project plan?

The good news, I assured my client, was that he had a lot
My client’s suspicions raised even further when I showed
of company in his situation. The better news was that it’s
him this one. “Didn’t we answer that in the first question?”
not that difficult to get out of the psychological rut which
leads project managers to create useless project plans, Well, yes and no. When we asked the first question we
post them, then ignore the hoary artifact in favor of more defined a use and an audience. In this question, we try to
mutable spreedsheets or calendars. dig down and figure out who will interact with the project
plan and in what ways. Some of this is contextual. In one
I prescribed him a simple remedy - four questions I
organization the PMO may dictate that developers always
always ask myself before I sit down to wok on a project
create and update their own tasks, while another may put
plan. These questions are as follows.
all the weight onto the project manager’s shoulders.
1: What do you want this project
I generally create a chart when I try to answer this ques-
plan to do?
tion. In the first column I put roles and/or names if I know
My client’s eye’s crossed when I gave him the first ques-
them. In the second column I put in how I expect them
tion. “A project plan organizes project work in a reportable
to interact with the project plan. In the third I put in how
fashion” he mumbled, trying to understand what the frak I
frequently they will interact with it.
was saying.

A project plan is, when we get right down to it, a docu-

ment. Documents exist for a variety of reasons. We use
them to record information, to communicate information
to one or more audiences, to brainstorm possibilities,
or as records of exercises undertaken to understand a
problem to name just a few.
The first step to creating a “useful” project plan is to figure
out what, in a given context, we need the project plan to
convey in order for it to be useful. A project plan written
to satisfy auditors must meet very specific criteria which
might not have anything to do with actually running a proj-
3: What will the project plan
contain?
“Ummm…” my client said. “Don’t project plans contain
tasks, dates, and precursor information?”
By this time, he had pretty much figured out my standard
“yes but” answer. Yes, a project plan by convention
contains all those things.
However, the real question is what tasks? How do we
filter and vet the vast amounts of process information
required to run a project into a useful document based
on what we need it for and who will interact with it? Do

40
we just drop everything into the project plan and hope
someone will get around to updating it? Do we use a
very minimalistic, critical path kind of approach. If we do
the later, how do we determine what needs to be in the
project plan and what doesn’t?
corporate setting can become unwarrentedly challenging
due to politics, lack of focus, and compromises which the
author might know nothing about. This situation unfortu-
nately dooms the fledgling project manager, but that’s just
the way the world works sometimes.

I wish I had a handy trick for making this filter. Unfortunate- Conclusion
ly, this is one of those “technique=time+context+person”
Using these four questions, my client did manage to
things. How we build the filter depends entirely on the
improve his project managers’ project plans. They ran into
answers to the previous two questions along with a host
some other, more complicated, political situations later on
of other process related variables. This is why, I suppose,
which they found the questions useful for as well. But that
we have consultants.
is another story…

4: Why is the project plan

important?
“Okay. I get the first three. But this is…” I thought I would
cut to the chase, because it looked like my client was
about to get a headache.

Every document can be important in at least two contexts

- the author’s and the reader’s. It’s vitally important to
differentiate between the two, otherwise we end up with
yet another confused mess involving poor communication
and broken expectations.

For an author, the act of writing the document is often

sufficient to organize his thoughts and allow him to move
forward. He may never have to revisit the document again
to gain benefits from it. We generally call this a success,
especially if we see a positive improvement in the author’s
productivity or development.

For a given reader, the document is only successful if it

meets his expectations about what information he will
find. To use this blog as an example, if I titled this article
“How to make a great cake”, my gentle readers would
justifiably want to flog me. For a project plan, we have to
know why a reader feels the document might be impor-
tant to him. Then, and only then, can we hope to meet his
expectations.

Each author can with a little bit of work uncover his own
motivations. Uncovering the why of a document in a

41
During the Project 2
10 ways to get a slipping project back on track
This information is based on the articles “Correct your
off-schedule project with these techniques,” and “Apply
these techniques to get your project back on schedule,”
by Tom Mochal.
Anyone who’s worked on project teams knows that a vari-
ety of factors can move a project past its deadline. It’s not
uncommon for some of the work to be harder than origi-
nally anticipated or to have turnover on the project that
requires you to bring new people up to speed. Sometimes
you discover that activities were simply underestimated.
Regardless of how it happens, many times you’ll find that
you’re trending beyond your committed deadline date. If
you discover that happening, your first obligation as the
project manager is to try to determine the cause. If you
look for remedies without knowing the cause, the situa-
tion will probably recur. Your second task is to try to make
corrections that will get the project back on track.
At the beginning of a long project, you have many options
to solve your problem. But toward the end, your choices
dwindle. Look at this list of techniques and see which ones
can be applied to your situation. Note that this list is not pri-
oritized. Some of the techniques may work in one instance,
while others could be applied better in another situation.
1:Work overtime
Everyone hates it, but one logical place to start is with
overtime. If people work more hours, they can get more-
work done in the same amount of calendar time. Overtime
may be the best option if you’re close to the end of the
project and just need a final push to get everything done on
schedule. If you’re toward the end of the project, you also
may be able to issue comp time after the project is
completed. If you’re still early in the project, there are
probably more effective strategies. This option may
also have cost implications if you need to have contract
resources work overtime.
2: Reallocate resources
The project manager must first understand what activities
are considered most vital to the project’s success, or on
the “critical path.” After all, if the project is trending over
deadline, by definition it is the critical path that’s late.
Once you understand the critical path, see if resources
can be moved from other activities to help resolve the is-
sue. This will allow you to get the project back on track by
delaying or stretching out some work. Be careful, though:
Delaying some work may end up changing the critical
path. Always make sure you double-check the critical
path each time you change the schedule.
3: Double-check all
dependencies
Schedule dependencies represent activities that must be
completed in a certain order. For example, if you’re build-
ing a house, you cannot start putting up the frame until
the foundation is poured and dried. If you’re trending over
your deadline, you should revalidate dependencies, since
it’s possible that the schedule is being lengthened by
invalid dependencies between activities. Invalid
dependencies may make it appear that activities must be
performed sequentially, when they can really be done in
parallel. Sometimes the scheduling software accidentally
adds a dependency. Sometimes the project manager adds
the dependency but on later review decides it doesn’t re-
ally exist. It might make sense to have the team members
review the schedule to see if they find dependencies that
the project manager thinks are valid, but that they know to
be invalid. Check all dependencies to make sure you have
all your facts correct before you move into more drastic
measures to bring the project back on schedule.
4: Check time-constrained activities
Time-constrained activities are those with durations that
don’t change based on the number of resources applied.For
example, you may be allocating team members to a five-day
42
class. The class takes five days if one person attends, and it
takes five days if 10 people attend. Check all of these time-
constrained activities to validate the timeframe. Perhaps
you’re making assumptions that could be changed with a
different approach. For instance, if you allocated three days
for a contract to reach a client, perhaps the time could be
reduced to one day by paying more for overnight delivery.
5: Swap resources
I mentioned that the first thing to do when you’re trending
over your schedule is to determine the cause. One cause
you may find is that you have one or more resources that
aren’t as productive as you planned. Perhaps
certain team members don’t have the right skills. Perhaps
they aren’t as productive in this particular area as they are
in other areas. Regardless, there may be opportunities
to replace resources. In some instances, you can sim-
ply swap people who are working on different activities
within your project. Other times, you may release a team
member and bring in another person. Remember that
the activities on the critical path are key. You may have
options to assign a more productive resource to those
activities, while reassigning a less productive resource to
noncritical path activities. If the activities off the critical
path are delayed, you may still be okay in terms of meet-
ing your overall project deadline.
6: Crash the schedule
Crashing the schedule means applying additional re-
sources to the critical path, the sequence of activities that
must be completed on schedule for the entire project to
be completed on schedule. It’s always possible to just
throw more resources on the critical path, but crashing
also means you try to get the biggest schedule gain for
the least amount of incremental costs.
For example, if one person were assigned to complete
an activity in 10 days, you could see whether two people
could complete it earlier. If two resources can complete
the activity in five days, you may not be adding any ince-
43
mental cost to the project, since you’re applying twice the
resources for half the time.
In another example, if two people can complete the work
in six days, you will have accelerated the schedule at
an incremental cost of two workdays (two people for six
days vs. the original 10-day estimate). In this example,
you could further crash the schedule by applying three
resources. Perhaps then the activity would take four days,
or four and a half days. Typically, the more resources you
throw on an activity, the more the incremental cost will be
and the less incremental timesavings you will receive.
The additional resources may come from within the proj-
ect team or they may be loaned temporarily from outside
the team. One of the goals of crashing the schedule is to
minimize the incremental cost. However, crashing -- in
exchange for completing some work ahead of schedule
-- usually leads to some incremental cost increase to the
project. If cost is not as important as the deadline, crashing
a set of activities can result in accelerating the schedule.
7: Fast track it
Fast track means that you look at activities that are
normally done in sequence and assign them totally or
partially in parallel. Back to our home-building example,
you can’t construct the frame until the foundation is dry.
However, if the house is large enough, you may have
options to fast track by starting to erect the frame on the
side of the home where the foundation was poured first.
The foundation will start to harden there and might allow
you to erect the frame on that side, while the foundation
on the far side of the home is still drying.
Another example involves designing an IT application.
Normally, you wouldn’t start constructing a solution until
the design was completed. However, if you were fast
tracking, you would start constructing the solution in
areas where you felt the design was pretty solid without
waiting for the entire design to be completed. Fast track-
ing usually involves risk that could lead to increased cost
and some rework later. For instance, in our example of
designing and constructing an application, it’s possible
that the design might change before it is finalized, and
those final changes may result in having to redo some of
the work already under way.
8: Prevent all scope change
Many projects begin to trend over their deadline because
they are doing more work than they originally committed
to. This could be a result of poor scope change manage-
ment or it could be that small changes are being worked
in under the radar screen. If you’re at risk of missing your
deadline date, as the project manager you must work with
the client and team members to ensure that absolutely no
unplanned work is being requested or worked on, even if
discussion still might need to take place as a last resort. It
may be an option to complete this project on time with less
than 100 percent functionality and then execute a follow-up
project to complete the remaining requirements.
Determining priorities
I’ve pointed out 10 areas to examine if you’re behind
schedule. Obviously, one solution is just to deliver the
work at a later date. In some cases, that may be perfectly
acceptable. However, the assumption here is that the
scheduled completion date is important to the client.
Some of these techniques don’t require any incremental
budget. You should look at them first, if possible.
Other techniques to accelerate the schedule will result in

it’s just one hour. All energy should go into accelerating increased cost to the project. If the deadline date is more

the agreed-to core work. important than costs, these techniques should be applied
next.If the deadline date is extremely important and you
9: Improve processes can’t move the schedule or the budget, there may be
When you look at the cause for the project trending over options associated with scaling back the scope of work.
schedule, you may find that some of the internal workpro- Usually you can complete less work faster. Once you
cesses could be improved. Solicit team member feedback know the cause of the problem and your budget flexibility,
and look for ways that are within your team’s internal you can determine the best actions to undertake to get
control to streamline processes. For instance, perhaps you you back on track to hit your deadline.
have a daily status meeting that is not providing value and
that can be scaled back to once per week. You may also
find bottlenecks in getting deliverables approved. If you dis-
cover delays caused by external processes, try to negotiate
changes to the processes going forward, at least on a tem-
porary basis. For example, you may find that activities are
being delayed because people need towork on their yearly
performance reviews. While these are important, perhaps
the timing of completing the reviews can be changed to
allow critical project activities to be completed on schedule.

10: Scale back the scope of work

One option that is usually available is to look at the work
remaining and negotiate with the client to remove some of
it from the project. If you think some of the remaining work
is not core to the project, you could discuss eliminating it
quickly. If the remaining work is all core to the solution, this

44
10 signs that your project is about to be cut
It is an unfortunate reality in the IT industry: A large from outside the organization; that can signal that an “axe
number of projects are cancelled before they are com- man” has just been put in charge.
plete. This would not be a problem if the IT industry were
3: Money woes abound
like many other industries, where the labor pool is made
When a company or organization is financially strug-
up almost exclusively of permanent employees. But the
gling, projects that are not showing immediate ROI are
IT industry is filled with temporary employees, contrac-
in particular danger. Even long-term investments that are
tors, consultants, and even permanent employees hired
projected to deliver a big payoff can be cut. Management
specifically for a particular project. So when a project is
all too often believes that IT projects can be put on hold
cancelled, workers lose their jobs. Knowing the signs of
indefinitely until the budgetary constraints are relaxed. IT
an impending cancellation can help these workers land on
pros know that things do not work this way—but good
their feet. Here are some signs to watch out for.
luck explaining that to an executive tasked with a general
1: Project sponsors and cost reduction. The worse the budget crunch, the more
stakeholders disappear risk there is that your project may be cut, regardless of
One of the surest signs of the imminent demise of a how good it is.
project is the disappearance of project sponsors and
stakeholders. This vanishing act can be a cause or a
4: Your project is a “black hole”
Some projects seem to be black holes: Money, people,
symptom of the collapse. On the cause side, when the
and other resources are sucked in, and nothing ever
sponsors and stakeholders move on to other things or
comes out. These projects are typical Dilbert scenarios,
other companies, their projects wither on the vine. On the
complete with constantly changing requirements, scope
symptom side, people’s careers are linked to their proj-
creep, moving targets, and so on. After a certain point, the
ects. When a project is sick, some people put distance
phrase “throwing good money after bad” starts getting used
between themselves and the project, and sometimes they
in executive meetings when your project is under discus-
are forcibly removed. If the people who were behind the
sion. When you’re over budget or past deadline by more
project suddenly are no longer around, one way or the
than “just a bit,” it is a roll of the dice whether the higher-
other, watch out.
ups will be willing to put more money and other resources
2: Changes in management into the project, or whether they’ll just throw in the towel.
are rolled out
Major changes in management always carry some risk 5: Management keeps discussing
to existing projects. After all, the new head honcho may
project cancellation
Some projects walk the razor’s edge between cancella-
not see the upside of a project like the previous boss did.
tion and continuation on a regular basis. It’s a normal and
Be wary when management changes, especially if it was
natural part of the project management process to have a
a sudden and/or involuntary change. When a manager is
few go/no-go points in the plan or to have milestones that
removed, all of his or her decisions are open for reevalu-
must be met for the project to be allowed to continue.
ation, and that means that your project’s neck is already
What is not healthy is when the topic of project cancella-
on the block. Be especially wary if the new leadership is
tion comes up outside of those planned points, especially

45
when it happens repeatedly. This may seem obvious, but
too many workers seem to be completely oblivious to the
dangers of this situation. When there are enough reasons
to discuss project cancellation that it comes up frequently,
it will get cancelled unless something major changes.
6: Your project becomes a tool
of office politics
Does everyone hate your boss? If so, your project is in
their sights. Even good projects are used as weapons in
vicious political battles. Your leader’s opponents argue for
the cancellation of the project to diminish the prestige or
resources of your boss or to cause embarrassment. It’s a
shame that executives behave like this sometimes, but it’s
a fact of life. When your boss is being stabbed in the back
and his or her decisions are constantly being questioned,
your project may be vulnerable, regardless of its merits.
7: Poor leadership casts a shadow
on the project
Of course, sometimes your boss’ detractors are right,
and your manager really is making a mess of things. If
you make fun of your project leaders behind their backs,
beware; someone else with a lot more pull is probably
sniping at them too. The manager who is obviously inept to
the staff is eventually going to be exposed, and when that
happens, your project will be at risk, even if it’s going well.
8: The project is successful,
but the product fails
Every now and then, there is a project that is completely
successful: The product shipped on time and within
budget, all of the goals were met, and so on. And then the
product itself completely tanks for one reason or another.
Maybe it’s priced too high, or possibly a new competitor
came onto the market out of left field with a better
product. Your market may have experienced an unforsee-
able and severe shift in direction right around the time your
product rolled out. For whatever reason, your project was
successful by every measure of project success. But the
product that resulted is a total failure. You may be given very
little time to do something to make the product successful—
and if that doesn’t happen, they’ll be closing up shop.
9: Your project has low visibility
In every company, some employees come in every day
for eight hours, and no one seems to know what they do,
why they are there, or even what their names are. And
when the layoffs come around, those employees are the
first to go. Some projects are like this too. For whatever
reason, they simply lack publicity or even recognition.
Sometimes, this is on purpose; the company is doing
something super-secret and wants to keep chatter to a
minimum. But most of the time, it is an indicator that your
project either is not producing anything useful, or your
project leaders are not doing a good job evangelizing your
work. Regardless, projects with low visibility are at risk
of cancellation. Eventually, someone is going to ask why
resources are being spent on it. And if no one can explain
the purpose of the project, it will be decided that the
project is not needed.
10: It truly is a bad project
Once in a while, management actually gets it right and
cancels a bad project. Black holes (see #4) are not
always bad projects; they may have simply been scoped
incorrectly at the beginning, or maybe some bad deci-
sions were made. Nevertheless, some projects truly
deserve to be cancelled. For example, if there is already
an established competitor on the market with a better
product than you’re planning or that it sells for less than
your product will sell for, your project deserves to be cut.
Or maybe you keep missing milestones or are way over
budget, and the milestones and budget were reasonable.
It may simply become clear that the end product will
never be successful in the marketplace. If it’s obvious
to everyone on the project that it is a bad project, it will
become obvious to the “Powers that Be” as well.
No one likes to think about their project getting cancelled.
But it is a reality we all have to face at one time or another.
The ability to foresee the likely cancellation of your project
46
is an important skill for keeping your career healthy. An
optimistic attitude about your work is always welcome at
the office and is part of being happy, but you may need to
balance it with a regular dose of objective consideration
so you can decide whether it’s time to move on before
someone else yanks the rug out from underneath you.

47
Sustain and broaden customer focus
outside of your projects
As a project manager or business analyst, you have an
important role outside the scope of customer projects.
Your work outside the context of projects helps to identify
and resolve issues and concerns, and build positive
relationships between IT and customer stakeholders.
While stakeholders may have relied on your good leader-
ship in the last project, they may still harbor ill feelings
about your IT department in general. The customer may
have longstanding and unresolved technical issues that
will have to be overcome. Middle management may want
IT to improve its support process and upper management
may worry that recent cost overruns predict the outcome
of future projects. All of these issues and concerns can be
resolved when a project manager steps outside the scope
of the project.
Expand your knowledge about
the customer’s business
You can begin your outside-the-project work by improv-
ing your level of understanding about the customer’s
business. The International Institute of Business Analysis
(IIBA) in their Body of Knowledge defines this understand-
ing as “capturing the necessary view of the business to
provide context to requirements and functional design
work for a given initiative and/or for long term planning”.
If you are a business analyst, a working knowledge of
your customer’s business is critical to the success of fu-
ture projects. For example, you should know the industry
jargon, the customer’s operational practices, and their or-
ganizational vision and goals. You should also understand
the motivations and interests of your customer’s clients.
There are many ways to gain this knowledge. If you
are new to the industry, convince your boss to let you
spend time observing your customer’s operations. Read
representative samples of your customer’s process
documentation. Read industry-specific journals. Attend
conferences and talk with vendors and your customer’s
peer organizations. Your customer’s marketing staff may
be a good resource for broad information about their
clients’ interests.
Capture stakeholders’
perspectives
Sustain and broaden your customer focus by building a
positive, long-term relationship with stakeholders. Be-
tween projects, invite a stakeholder to lunch, or out for a
cup of coffee. Most people welcome a chance to get out
of the office and chat.
Come to each meeting well prepared. Check with your
help desk and familiarize yourself with significant issues
the customer has with IT systems. If you need clarification
on an issue, talk with those technologists who routinely
work with the customer. Also, draft a set of open-ended
questions to ask the stakeholder when you meet.
Where I live, in the Midwest United States, we often start
conversations with small talk, which is a good way to help
you and your guest to settle into a good conversation.
I might ask about his or her children, or query about a
recent bike or sailing trip. Eventually, I’ll ask about their
current systems. Are they working properly? Is everyone
trained? Is the new system fully adopted? Is support from
the help desk working well?
Listen carefully for an issue. Make sure you understand
it, take ownership of it, and promise to follow up with the
stakeholder. If there is time in your meeting, ask about
concerns the stakeholder may have about operations. Are
there processes that seem inefficient? How is the cus-
tomer working to reduce costs and increase profits? Ask
about new initiatives they may be considering.
48
Try to meet periodically with the same person. Over time, emotions for a moment. How would an objective observer
such meetings build mutual trust, and the stakeholder view this conversation? This third person might remind
begins to see you as valued advisor. You benefit by you that IT signed-off on testing as well. How would this
expanding your knowledge of the customer’s business, observer encourage you respond?
and by understanding the stakeholder’s perspectives and
(A valuable resource for understanding this approach is
interests. You also “bank” goodwill. When a crisis eventu-
Difficult Conversations by Douglas Stone, et al.)
ally arises, you both have a relationship from which you
may reach a mutual understanding and quickly resolve Set aside your emotions. Listen to the stakeholder and
the issue. empathize, then consider possible solutions, make a rec-
ommendation, and help the stakeholder understand what
After the meeting, follow up with the stakeholder regard-
you propose. If the he or she agrees to the approach,
ing any identified issues. A phone call works well. After
implement the solution and follow up. This approach often
thanking him or her for their time at lunch or coffee, com-
defuses the stakeholder’s emotions. Remember to man-
municate the issue resolution. Also, indicate the progress
age the issue until it is resolved — even if someone else
made in resolving any remaining issues and specify when
corrects the problem.
you or someone from your department will follow up with
new information. Educate stakeholders
A fourth straegy involves taking some responsibility for
Support the stakeholder
educating your customer’s stakeholders. Many IT-oriented
I find it helpful to take a view of systems beyond the
magazines, journals, and on-line media periodically focus
narrow framework of IT. If you remember that technology
on a specific industry (e.g., a government, manufactur-
is just a tool, you can transform yourself from thinking
ing, or service sector). Since a stakeholder is unlikely to
“software solution” into thinking “customer system” — a
encounter these IT resources on their own, be sure to
perspective that includes users, business processes,
pass along articles that may be of interest. The stake-
physical infrastructure, and organizational culture. By do-
holder may appreciate knowing about industry peers, and
ing so, you reframe your perspective from “IT-centric” into
learning how a challenging problem was solved.
the more valuable “customer-centric” view.

Initially, it may feel strange to take this step with a

This new perspective has the effect of helping you
stakeholder. If so, give them a phone call and indicate you
improve customer support. For example, as you write an
recently read an article that might interest them. Ask if
e-mail response to an angry stakeholder’s question, you
they would like to get the Web link, or would like to review
are better prepared to consider how your message will be
the pages you tore out of the magazine. Whether they
received. If your response angry as well, set the e-mail aside
are interested or not, you have probably left them with a
and pick it up later. Always be mindful of the larger goals
positive feeling about your interest in them.
you hope to achieve. Would it be more effective to talk with
the stakeholder by phone or meet with them in person?
Advocate for stakeholders
Even with this new perspective, it is natural to feel As a final suggestion, become an advocate. As you build
defensive when a stakeholder calls you to complain about a positive relationship with a stakeholder, you may even-
a serious bug in the new production system. It wasn’t tually find him or her soliciting your opinion about a new
your fault the customer failed to test adequately before technology your IT department may be adopting.
implementing the new system. Try to step outside of your

49
To help stakeholders understand the impact on their
business, consider developing an exploratory user group.
Invite stakeholders to attend the meetings, while being
mindful of their backgrounds and interests. Create oppor-
tunities for them to understand the new technology from
the perspective of their business. Explain how it might
improve their operations, increase their profit margin, or
reduce their costs. Help them appreciate the technology’s
strengths and weaknesses, as well as the opportunities
and threats associated with using it. While stakehold-
ers may welcome the learning opportunity, they will also
value having a forum in which voice their interests and
concerns.

As an advocate, you also have the role of ambassador on

behalf of your customer to your own IT department. Try
to represent your customer’s viewpoints when you feel
that IT may be ignoring or misinterpreting them. Explain
to technologists the customer’s perspective. If neces-
sary, facilitate a meeting between the stakeholders and
technologist to clarify and resolve the misunderstanding.

Next Steps
Without strong relationships with stakeholders, it is too
easy for us to fail in serving our customers. Valued tech-
nology is built on the foundation of valued relationships.
By sustaining and broadening a customer focus outside
of projects, you and your IT department become your
customer’s most valued technology advisor.

50
Create and sustain a customer focus within projects
Whether the clients you serve are inside or outside your
organization, creating and sustaining customer focus is
crucial to your success as an IT department. Countless
articles have heralded the destruction of information tech-
nology’s ivory tower and the resurrection of an IT service
closely aligned with the vision and goals of its customers.
As with most human endeavors however, there is room for
improvement. Consider the extent to which your technol-
ogy department is aligned with your customer’s interests.
Take a moment and review a representative sample of
the contact points you have with your customers and ask
yourself some questions.
What do customers say during post-project reviews about
your department? Do your customers have confidence
that current projects will be delivered on-time and on-
budget? Is communication effective (and respectful) be-
tween your department and its customers? If a customer
had a chance to restart a recent project, would he or she
choose your technology team to run it?
Worried? As a project manager or business analyst, you
have a unique opportunity to understand your customer
needs, and you can lead your IT department in creating
and providing valued products and services. Let’s begin
with actions you can take within the context of a project.
Collaborate with customers
Whether as a project manager or business analyst, you
should figure out a way for IT and the customer to
collaborate on each project. There are four key points to
consider:
1. Start with a project with joint ownership. Collab-
orative projects get a good start by having two
sponsors — one from customer management,
and one from IT management. The people in
this sponsorship role have to be high enough in
51
their organization’s food chain to tap resources,
allocate funding, and knock down hurdles. Of
course, both sponsors have to support the project
and be dedicated to seeing the project succeed.
2. Build a project team that consists of both
technologists and customers. Of course, the
technologists should know the technology, but
the customer’s representatives should be busi-
ness experts as well. Do what ever you can to
recruit the subject matter experts who work well
with others, who are neither shy nor overbearing,
and who are highly motivated to drive a success-
ful project. The concept of a joint project team
works remarkably well in each project phase
— discovery, design, development, testing, and
implementation.
3. Create joint ownership of the project outcome.
Sometimes this dictum means, “Eat your own
doggy chow.” Many years ago, I knew a software
company that provided payroll systems to its
customers, but never seemed to use the product
to pay its own employees! You can’t stay in busi-
ness that way, and they didn’t. It will help if you
can ante to match the customer’s financial com-
mitment to a project. Be creative.For high-profile
projects, consider putting your company’s reputa-
tion on the table by announcing your joint venture
to the media when the project starts, and provide
periodic news releases as the project progresses.
Have some of the early development be con-
ducted by your technologists at the customer’s
site. Consider adopting several of the customer’s
technologists, train them, and embed them in the
development team. Have some of your develop-
ment team handle incoming help desk calls for
the first few days following implementation.
 4. Remember that if you care about people and can
create positive relationships with them, nearly
anything is achievable.
Communicate with people
Start first by learning to listen. You must first understand
the challenges your customer faces from their perspec-
tive. To do so, actively listen to your customer. As the next
step, demonstrate your interest in solving each issue by:
Empathizing with each issue they identify
Considering alternative solutions
Identifying one or more workable solutions
Making a recommendation based upon known
constraints
Helping the customer fully understand what you
propose
Second, hold open the communication pathways. During
your project, talk with stakeholders more often than you
have in prior projects. Routinely check-in with stakeholders.
A periodic phone call demonstrates that you are interested
in their perspective and seek to learn their specific project
concerns. These phone calls help you identify new risks and
issues before they gain too much steam. Also, check-in with
the sponsor from time to time. In addition to regular project
status reports to the sponsor, you should hold periodic
face-to-face meetings with the sponsor as well.
Manage risks
You can avoid most surprises by searching for trouble in
a project. Build time into the project plan to evaluate risk
periodically. Consider what stakeholders mentioned when
you last talked with them. What worries them? Are there
project risks you have not identified? Has the likelihood
of a risk’s triggering event increased? What do these risks
mean to your customer and the project? What political,
economic, or cultural forces threaten the project as you
consider the ecosystem outside the project?
As an extension to your role as a communicator, you owe
the stakeholders and the sponsor a levelheaded assess-
ment of these risks. Start by discussing these risks with
your project team, determine a strategy for handling them,
and assign someone to implement the strategy. As neces-
sary, escalate risks to the sponsors in your periodic status
report. If you need it, ask for help from them.
Celebrate accomplishments
Smile. Have fun with the project and help the project team
have fun too. Although some projects feel like a death
march, the positive and energetic attitude you demon-
strate is infectious. Have a party (or two). Invite the project
team out to lunch from time to time. Even if everyone
pays their own way, a lunch is a wonderful way to rebuild
enthusiasm and strengthen relationships.
Be sure to reward those who produce results beyond
what is expected of them. Whether you have a budget
for bonuses or not, a heartfelt, handwritten note of
thanks to someone is priceless. Send a card to someone
for an innovative idea, a clarifying perspective, or
sustained enthusiasm.
Next Steps
We all lose site of our customer’s interests at some point
during a project. While these behaviors have helped me
stay focused, I cannot suggest you adopt them without
first making a fundamental shift in how you and your IT
department value customers. You have to get up in the
morning and declare to yourself (and the world) that your
customers are your most valuable asset. Once you accept
this principle, customer focus follows easily. Strive to be
your customer’s most valued technology advisor.
52
10 tips for meeting IT project deadlines
Erratic and poorly estimated timelines, scope creep, personnel failures. This “plan B” acts are your support
unexpected staff illnesses, and supplier failures are just a system when things don’t go as expected.
few of the things that could (and probably will) go wrong
with your project. And because time is today the most
5: Estimate and allocate
Assign roles and responsibilities to team members and
common metric to measure efficiency, the schedule
ensure that each task has a clear owner. Use project man-
delays caused by these events can end up costing you a
agement tools and Gantt charts to record who does what
fair amount of money (in addition to a possible damaged
and identify start and end dates for each activity. Failure
reputation). Here are some tips to help you plan your next
to assign clear responsibilities for each task can lead to
project and ensure that it comes in on time, under budget,
overlapping responsibilities, duplication of efforts, exces-
and at a high quality level.
sive time spent on activities, and inferior product quality.
1: Analyze the requirements in detail
Understand exactly what the project involves, down to
6: Modularize work
Break down main activities into sub-activities, until each
the smallest details. Ask questions to clarify ambiguous
activity is complete on its own and independent of other
areas. Finally, hire professionals to clearly document the
activities. Arrange them in logical order and then start
business requirements, the functional specification, and
executing the smallest activity in the order of occurrence.
the design requirements. Watch out for scope creep; it
can single-handedly destroy all the work you’ve done.
7: Avoid too many meetings
If the need arises, take aggressive steps to reduce the
Plan meetings to discuss the status of the project or on
scope of the project or to avoid adding unplanned new
an as-needed basis to address immediate problems.
features that require significant integration time.
Long, unending meetings with no clear agenda and hence

2: Map available resources no clear outcome only waste time.

Map available resources with requirements to ensure that

8: Write things down
there are enough personnel on site to complete the job.
Document the failures and successes of the project. This
Identify all relevant infrastructure — hardware, software,
is important; it acts as historical information for similar
human resources, tools, documents — required to execute
activities in other projects. Use a project dashboard to
the project well before the project development starts.
obtain a visual, high-level overview of the project and to

3: Perform training and measure the progress of project activities. Take stock

knowledge transfer of the project at each milestone and update the project

Include training, if any, as part of the project timeline. Don’t dashboard each time.

treat training as something team members do on their own

9: Beware of follow-the-sun
time, but account for it in the project schedule and budget.
development
4: Identify risks If there is a follow-the-sun development model (a continu-

Identify the potential risks and create contingency plans ous engineering environment with development

to deal with them. Develop a backup plan to meet the happening 24/7 across the globe), ensure clear commu-

project deadline in case of unexpected process or nications to avoid misunderstanding between co-located

53
or cross-country-located team members. Coordinate well
and regularly so that nothing falls through the cracks.

10: Escalate issues

Escalate issues to management as they occur and
brainstorm on solutions to problems. Trying to remedy
problems after they’ve deteriorated beyond recovery is
the last thing you need.

54
10 reasons why use cases are indispensable
to your software development project
Well-written use case narratives (or simply “use cases”)
offer the analysis, development, and testing teams an
invaluable guidebook. A use case (different from a UML
use case diagram) is a formalized story that describes
how someone procedurally interacts with an existing or
proposed system and they should be part of every project
managers’ permanent tool set.
Introducing use cases
Imagine flying to an unfamiliar foreign country where
you plan to rent a car and tour the sights. Most people
wouldn’t consider starting this trip without a good
guidebook. Despite the obvious value of a guidebook’s
roadmaps and narratives, we information technologists
too often embark on software development projects with-
out them. As a result, development teams often wander
far from the project objectives - at considerable expense
and delay.
Use case narratives were most notably popularized in
Writing Effective Use Cases, by Alistair Cockburn.
What does a use case look like? The document, Cus-
tomer gets cash from an ATM, available in the download
version of this post, represents a detailed description of a
business process. The structure of this sample use case
reflects a framework I’ve designed and used in several
large projects. While the structure of my use cases differs
somewhat from Cockburn’s, it accommodates what my
analysis teams have generally needed to capture process
requirements.
10 reasons
I routinely encourage analysis teams to develop use
cases. Here are ten reasons why they are part of my
permanent toolset.
55
Use cases help the
analysis team…
1. Improve communication among team members
Collaborative effort enhances the success of any team.
As the team members work to describe business pro-
cesses, use cases provide a repository of team members’
business knowledge. As a written document, each use
case spawns meaningful discussion within the group.
The axiom, “the whole is greater than the sum of the
parts”, applies here. Group discussion exposes in-depth
viewpoints that would otherwise remain hidden. With use
cases, the team captures these perspectives while iden-
tifying the related business goals, conditions, and issues.
The result is a comprehensive and meaningful story about
each business process.
2. Encourage common agreement about system
requirements
The process of writing and revising use cases produces
three important outcomes in the analysis team — clarity,
consensus, and commitment. Remarkably, it is common
for stakeholders to be uncertain about how a process they
own actually works! Writing a use case helps stakeholders
align the narrative with the details of an existing process.
In a recent project, it became clear that stakeholders
could not agree about the specifics of several core pro-
cesses. However, consensus came quickly as the team
wrote and revised use cases. For many stakeholders,
these written documents offer a foothold on a sometimes
bewildering mountain of complex business processes.
Remarkably, use cases often help stakeholders reach
common agreement on “best practice” processes as well.
In a facilitated group setting, divergent perspectives are
welcomed, understood, and appreciated. As a
by-product of this agreement, team members inevitably
commit to support improved processes to both manage-
ment and peers.
3. Reveal process alternatives, process exceptions,
undefined terms, and outstanding issues
I always have the analysis team start a use case by devel-
oping the “Main Course of Events” (see the sample use
case). As the group develops a coherent and ordered set of
process steps, team members tend to volunteer statements
that begin with the words “what about…” - a clue to previ-
ously unidentified “Alternative Paths” to a successful out-
come. The “Exception Paths” often arise in a similar way.
More of these become obvious when the team considers
what happens if any step in the “Main Course” fails.
As the facilitator of team meetings, carefully listen for any
jargon used by stakeholders. Write these terms down in
front of the group and ask for a definition for each one.
Later, you’ll add these definitions into the project glos-
sary. Also, listen for issues as they arise. Is a process step
fuzzy? Is there an area that needs more research, or an
item on which team members disagree? Write these down
as well and later include them in a project issue log.
4. Expose what belongs outside project scope
Constraints on the project may limit resources and/or
the project timeline. As a result, the analysis team may
need to prioritize development work, or separate project
deliverables into phases. You can help the analysis team
by creating a catalog of the use case titles, and arranging
them into some meaningful order (e.g., by sub-system or
umbrella process). With this catalog, the analysis team can
prioritize the use cases. They may decide that some fall
outside the project scope, or that some are not needed
in the first project phase. Either way, you have given the
stakeholders an opportunity to declare which functions
they need the most, or which ones they need first.
5. Transform manual processes into automated
processes
When software is being designed to automate aspects of
an existing system, the analysis team usually begins by
writing “as is” use cases to describe the current business
processes. While this effort is time consuming, the result
is valuable. Besides revealing the details of an existing
business process (including business rules, alternative
paths, and exception paths), you will create a launching
pad for the team’s imagination. As they are writing the use
cases, they often discover an improved process, recog-
nize unnecessary steps, or reach agreement on “best
operational practices”.
The “as is” use cases may also allow the system archi-
tect to propose high-level process flow diagrams that
represent how the new system could work. While the first
attempts may not be viable, iterative review and revision
by the analysis team may generate a workable architec-
ture for the new system.
Use cases help the
development team…
6. Understand business processes
Software developers often lack an understanding of the
customer’s business. It is easy to forget that software
systems should help business people get work done —
effectively, efficiently, and inexpensively. To achieve these
objectives, the development team must understand not
only the business process the software must support, but
also the process’ alternatives and exceptions. Use cases
provide this information in clear, structured language that
developers can readily understand. Use cases also offer
a valuable perspective on the stakeholders’ business
goals, assumptions, and operational rules. These features
provide developers with a solid foundation for developing
cost-effective solutions to business challenges.
7. Recognize patterns and contexts in functional
requirements
Developers may view a set of use cases horizontally.
For example, one use case requires a customer lookup
function. Another use case requires a similar function but
with customer data sorted in a different order. The clever
56
development team can find such patterns within a set of critical features were missing. The rooky analysis team
use cases. Patterns are often discovered in the “Busi- and I compared the delivered software to our use cases.
ness Rules” section of use cases as well. Developers may Although we created a long list of missing features, we
transform these patterns into universal software objects. challenged the developers to close the gaps rapidly. The
next installation was acceptable.
As another aid to developers, use cases also reveal
operational context. The “Stakeholders Goals”, “Pre- 10. Ensure the delivered software works properly
Conditions”, “Assumptions”, and “Post-Conditions” give While use cases significantly differ from test cases, the
developers a sense of how the software will be used. By former may be used to derive the latter. The “Assump-
reading these sections, the developer understands what tions”, “Pre-Conditions”, and “Post-Condition”, “Main
the role identified in the use case is trying to accomplish, Course”, “Alternative Paths”, “Exception Paths”, and
and what motivates him or her. “Business Rules” sections are all source material for
creating good test scripts. Bundles of use cases orga-
8. Prioritize work
nized into system-wide process flows become a source
Although the analysis team may have prioritized and
for writing comprehensive end-to-end test scripts. As an
winnowed the use cases, the development team views
added bonus, the testing team develops test scripts from
them from a far different perspective. As a good develop-
the use cases as the development team begins its work.
ment teams writes code, they search for coding efficien-
The test scripts are now ready for use as developers
cies. While the analysis team may want 12 use cases
complete programs.
completed in phase one, the technical manager and the
development team may see cost-savings in delivering Lessons Learned
phase one software for the 12 use cases, plus two more
While writing use cases may seem time consuming and
from phase two that are cheaper to build as part of phase
tedious, the result is a foundation for work by the analysis
one. Of course, the analysis team and the development
team, the development team, and the testing team. Use
should jointly consider the effect of this change.
cases provide a valuable return on the analysis team’s
investment in time and resources.
Use cases help the
testing team…
9. Discover gaps between the requirements and the
delivered software
Some years ago, I was asked to join a troubled project
in which the system design phase was nearly complete.
Unfortunately, detailed functional requirements were no
where to be seen, and the developers had already begun
writing code! In order to catch up, I taught a team of func-
tional users to write use cases themselves. Although we
completed the narratives quickly, the developers largely
ignored our use cases.

That condition changed, however, after the developers

installed their first software release. It was clear to us that

57
10+ project management mistakes (and what
you can learn from them)
Most of the project management mistakes I’ve made over
3: Stay on top of schedules
the years are due to a lack of concentration. The truth is,
“I simply forgot about the longstanding vacation plans of
when things are running smoothly or when you’re diverted
one of my crucial team members when working on the proj-
by other priorities, it can be easy to take your eye off the
ect plan. Fortunately, he managed to reschedule, but I’m
ball. I often mistakenly thought that even if things got a
still having to buy him beers just to keep the story quiet.”
little out of shape, there would still be plenty of time to
catch up.I asked some IT project management colleagues See the previous advice — the same comment about

and a couple of professional rivals to divulge their profes- professionalism applies.

sional gaffes. Here‘s a selection of their confessions and

4: Don’t second-guess
what can be learned from each one.
the right decision
This information originally appeared in the article “True “Last year, I was asked by two of my most respected

confessions: What’s your biggest project management developers if they could take a two-week training course.

mistake?,” by Patrick Andrews. It’s also available as a I had to refuse them, I thought, due to our departmental

PDF download.
1: Pay attention to details
“I realized that I’d been sending e-mail updates to the
client and spelling the name of his company incorrectly
for a month.”
It seems comparatively unimportant, but to that client,
the error is a sign that you don’t recognize his corporate
brand. Oversights like this will cause significant,
unnecessary friction.
2: Don’t mess up the
simple stuff
“At my last company, I accidentally overwrote the data
files for an online project plan, leaving me to re-create
large parts of the plan from scratch. I couldn’t believe
it when, later that year, I lost two people’s month-load
of work because I was using an unfamiliar, source-safe
revision-control package — with the wrong settings.”
budgetary situation. They left the company, citing my lack
of management ability as one of their main reasons.”
Maybe this manager could have handled the situation
better, but you have to make decisions and live with the
consequences. There’s no point agonizing about “what-
ifs” after the event.
5: Don’t pretend to know
what you don’t
“When I was quite new to project management, I was
embarrassed to admit my lack of experience in build-
ing embedded versions of programs, which I was pretty
familiar with. I thought, ‘How hard can it be?’ It turned out
that I had to work double-time just to stay in touch with
what was happening on the project, and it resulted in a
major cost overrun.”
Try not to get overconfident; that can often result in a
major egg-on-face scenario.

The moral is to make sure to be professional even when

you’re doing simple stuff like backups.

58
6: Don’t be afraid to admit your
limitations or ask for help
“I recently found that one of my projects on behalf of a
defense contractor was beginning to slide, but I was unsure
what to do about it in a very macho culture where any admis-
sion of a mistake would have caused me to lose respect.”
The best way to lose respect is to allow your project to
mess up. Every day you fail to communicate makes the task
harder. If you have this problem, get it out in the open today.
7: Learn to say “no”
“My CIO once goaded me into taking on another proj-
ect when I was already really working at capacity. I
lost focus, and a more important piece of work was
compromised.”This is such a common error because
most everyone needs to learn to say “no” constructively.
8: Don’t accept blame for
another’s mistakes
“A senior manager asked me to put together a feasibility
study. After I’d written a detailed plan and discussed the
work with several senior developers, I discovered that the
manager didn’t have an authorized budget. I was accused
of wasting scarce resources.”
Carrying the can for someone else is unfair. Perhaps the
manager will see this and cut you some slack the next
time you need a favor.
9: Forgive yourself and do
better next time
“When I was asked for an unscheduled progress
summary by my CEO, I panicked and left out a word in
my e-mail response. The whole thing was misinterpreted
and blown out of proportion. Even though the work was
completed on time, I’m sure that my professionalism is
still in question a year later.”
Don’t let personal history deflect you from making the
next job your masterpiece. To err is human — even in
project management.
59
10: Don’t underestimate
people issues
“I had a project that nearly came apart because I under-
estimated the impact of people issues within the project
team. We had quite a few new developers, a few more
experienced folks, and several contractors. The existing
folks were part of a strong union and had adopted the
“work to job description” mantra, whereas the contrac-
tors generally did whatever it took to get their deliverables
done. This created a lot of tension within the team as the
staff members felt the contractors were overstepping their
bounds (and really they were, in order to get stuff done),
and the contractors felt they were carrying the “slackers”
(and really they were, in some areas). A complete mess.
However, none of it was obvious until the tension started
to come to the surface. By then, the schedule was com-
promised and had to be reworked a bunch.”
Keep a better handle on the personal issues within the
team. Ask more questions, more frequently, to get at them.
11: Take nothing for granted
“One project I was involved in went down the tubes
because I didn’t check that the executive in charge had
actually read the technical spec he had signed off. He
then instructed a design agency to produce a product
that the client couldn’t use.”
Check that your senior management has read and under-
stands the project documentation.
12: Keep the end user involved
“After three months and many labor hours, we delivered
a RAD business tool the end users never used because
it didn’t provide the functionality they required. The tool
was trashed and we had to start again. The second time
around, I kept the user and other stakeholders involved,
and we delivered a business analysis tool they could use
and be proud of.”
Keep the user involved from beginning to end in a devel-
opment project. It’s the only way to be certain you will
deliver what they want.
Learn from your mistakes
to prevent bigger ones
Even though it may seem as though the high-pressure
field of IT project management doesn’t tolerate slip-ups,
carelessness is fundamentally different than failing while
trying to do your best. If you (or that rookie project man-
ager you’re training) can learn from your mistakes, then
you might be able to prevent big projects from spiraling
out of control.

60
10+ things that can send an IT project
off the rails
Depending upon the unique aspects of a situation, a mul- In reality, though, some projects are so critical to business
titude of reasons can cause a project to go out of control. survival that they can’t be stopped. Therefore, the cost
Here are some of the most common risk factors. overruns are simply absorbed or skillfully transferred else-
where. This means that project managers must manage
Note: This list, which is based on the article “How to iden-
their actual budgets against the planned budget and keep
tify a failing project” by Jason P. Charvat, is also available
their stakeholders aware of any deviation.
as a PDF download.

4: Scope creep
1: Sloppy requirements
When clients insist on ever-increasing changes to the
Every project depends upon solid user requirements
product being developed, scope creep can jeopardize
being firmly locked down prior to any work being under-
the project. I don’t know of too many project managers
taken. Failure to do so is a leading cause of project failure.
who can handle too many changes all at once. An even
Somehow, the trend is that many project teams think they
more difficult situation for a project manager surfaces
can get started by rushing the requirements-gathering
when new changes are introduced after the project has
phase. These projects are then eagerly started with
been launched. This usually drives up the cost, resource
incomplete requirements. If you are developing a project
requirements, deliverables, and completion time. Scope
using a standard waterfall methodology, any incomplete
creep needs to be managed and the project manager
requirements will have both a negative cost and schedule
needs to have a change control process in place to
impact on the project. On iterative development projects,
assess the impact and cost of the change and, possibly,
user requirements are still of utmost importance, but they
negotiate the change for a future release.
can be negotiated ahead of any actual development.

5: Poor planning and estimation

2: Schedule slippage
Those projects that are poorly estimated and planned
Many times, project schedules spiral out of control when
tend to fail both in cost and schedule, which eventually
dates and deliverables aren’t aggressively monitored and
causes the overall project to fail. Managers tend to start
tracked on a daily basis. All too often, managers leave
projects without relying on proper analysis and sizing and
issues unresolved for days, which then results in sched-
fail to consult subject matter experts or cost estimators to
ule overruns. I recommend that that you check project
validate how much project work packages will cost.
schedules daily.

6: Poor documentation
3: Budget overrun
Maintaining inadequate project documentation is cause for
Projects that run over budget are sometimes more prone
concern and should raise the red flag. Lessons learned from
to being canceled because senior executives are con-
many failed projects reveal that there was too little docu-
cerned about cash going into and out of company coffers.
mentation to adequately describe the project in its broader
If a project starts showing gradual cost overruns, it’s often
terms and serve as a clear communication channel.
still given a chance. But as the losses mount and show no
sign of recovery, canceling the project may be necessary.

61
7: New technology
Projects hat require integrating new tools and deploying
new vendor applications/devices are always far more
difficult because usually, only the vendor engineers clearly
understand the limitations and functionality of the prod-
ucts. This results in delays in project schedule and could
require weeks or months before the products are stable
enough to be deployed. If a project is undertaken using
new technology, managers should be aware of the associ-
ated risks and plan their schedules accordingly.
10: Poor project management
The person managing the project may not have the skills
or experience to pull it off. Yes, any project can be stuck
with a lame duck manager. In such cases, it may be nec-
essary to stop the project, replace the project manager,
make the necessary adjustments, and start again. The
departing manager should be given the option to provide
his/her version of the story, though, before moving on.
11: Poor testing
A big culprit on any project is having either too little testing

8: Poor communications or, in many cases - if a test team is involved - testing too late

One of the biggest reasons why any project goes bad in the process. Both testing and quality assurance need to

is due to a lack of communication. I have seen many be built into the project from the day the project is launched.

projects fail simply because no one understands what

to do and receives no communication regarding current
progress. Inevitably, this results in project failure.

9: Poor decision-making
Decisions that aren’t made at all and decisions that are
delayed due to second-guessing are both risk factors. In
addition, some decisions are so turned out-of-context as
responsibility for them is passed down the line that they
end up being made based on faulty information. This
doesn’t bode too well for any critical project.

62
10 signs that you aren’t cut out to be a
project manager
You’ve all seen top 10 lists of the best traits of a project leadership, hold them accountable, manage conflict, etc.
manager or the top 10 skills of a project manager. Howev- Some project managers say they could do a much better
er, project management is not for everyone. Many people job if they did not have to deal with people. If that’s how
have some of the traits to be a good project manager, but you feel, project management is probably not for you.
they also have many traits that make them a bad fit for the
position.Here’s my list of indications that you may not be
5: You don’t like to follow processes
Yes, I know no one wants to be a slave of processes. But
well suited to be a project manager. Note: These are not
you need good processes to be effective as your proj-
in any ranked order.
ects get larger. If you don’t want to follow good project
1: You are a poor communicator management processes, you are not going to get too far
It is said that more than 50% of a project manager’s time as a manager.
is spent in some aspect of communication. This includes
meetings, status reporting, e-mails, phone calls, coor-
6: You don’t like to document things
Of course, all things in moderation. I am not proposing
dinating, talking to people, and completing documenta-
that you have to love documenting to be a good project
tion. Some studies have shown that verbal and written
manager. But you can’t hate it, either. Many aspects
communication takes up 80% of the job. If you are not an
of project management require some documentation,
effective communicator (and you don’t care to be), don’t
including status reporting, communication plans, scope
go down this path.
changes, and Project Charters.
2: You don’t work well with people
If you prefer to stay in your office and focus on your own
7: You like to execute and not plan
When a client gives you a project, what is your first
work, you probably don’t have the collaborative ability to
inclination? If your first thought is to get a team together
be a good project manager. Good project managers need
to start executing the work, you probably don’t have a
to spend a lot of time with clients, stakeholders, and team
project management mindset. If you do not want to spend
members.
the appropriate amount of time to make sure you under-
3: You prefer the details stand what you are doing, you are probably not cut out to
Many people like to work on the project details. We need be a project manager.
people like that. But when you are a project manager, you
must rise above the details and become more of a del-
8: You prefer to be an order taker
If you think your job is to take orders from the customer
egator and coordinator. You must rely on others for much
and execute them, you may not be a good project
of the detailed work when you are a project manager.
manager. Project managers need to provide value on a
4: You don’t like to manage people project, including pushing back when the client is asking
You don’t have much of a project if you’re the only for things that are not right. If the client raises a request
resource. If you want to be a good project manager, you that is out of scope, you also need to invoke the scope
need to be able to manage people. You will not have change management process. If your reaction to scope
100% responsibility for people, but you will need to show

63
change is saying, “Yes sir, we’ll do it” instead of going
through the scope change management process, project
manage is going to be a struggle for you.

9: You are not organized

People who have poor personal organization skills and
techniques usually do not make good project managers.
If you’re going to manage multiple people over a period of
time, you need to be well organized to make sure that ev-
eryone is doing what he or she needs to do as efficiently
as possible.

10: You think project management

is “overhead”
No one can feel good about their job if they think the work
they perform is not value-added. Good project managers
understand the value of their work, and they understand
their work will result in a project coming in on time and on
budget with a good experience for the client and the project
team. If you think the work associated with project manage-
ment is overhead and non value-added, you’re probably
not the right person to be a project manager yourself.

64
10 ways to effectively estimate and
control project costs
Building a better bottom line is just as important for an IT problems with opportunity costs. Think of IT projects as
department as it is for the whole organization at the en- an investment portfolio; the idea is to maximize value
terprise level. Implementing sound financial management and appreciation. Baseline costs are food, clothing, and
within an IT framework is broader than simply being more shelter; we have to spend the money but it doesn’t have
efficient. Many factors are involved: an understanding of to overwhelm the budget.
the main drivers of IT costs, aligning IT spending plans
2: Acknowledge hidden IT
with overall business strategy, using financial resources ef-
spending impacts
ficiently, viewing IT expenditures as investments and having
Gartner estimates more than 10 percent of corporate
procedures to track their performance, and implementing
technology spending occurs in business units, beyond
sound processes for making IT investment decisions.
the control of IT. Several factors contribute to increasing

Estimating what a project will cost is only half the battle; hidden IT spending:

controlling those costs during the project and after

Flat organizational models more difficult to rein in
delivery is equally critical. In this article, we examine some
and control
methods to predict and manage costs, part of a sound
Virtual enterprise structures ostensibly set up
basis for overall IT financial management.
as nimble, agile organizational constructs but
1: Control baseline costs without regard for policy and procedure
Nondiscretionary money spent maintaining established
Changing organizational authority where busi-
IT systems is referred to as baseline costs. These are the
ness unit managers are given (or take) responsi-
“grin and bear it” costs, those required just to keep things
bility for decentralized technology spending
going. Baseline costs constitute around 70 percent of all
Selective IT outsourcing, in which a business
IT spending for the average organization, so this is a good
unit will independently decide it doesn’t need to
place to start. These costs tend to creep over time due to
participate in overall enterprise architecture to
the addition of new systems, meaning there’s less money
fulfill its departmental mission
available for discretionary project work. Worse yet, this
creep gives the appearance that IT costs are rising while The impact of all this hidden technology spending can

the value derived from IT investments stays the same or be profound and prevents IT from being able to control

actually goes down. project costs. Architectural pollution from rogue projects
can delay change, resulting in cost overruns and lost
Fortunately, baseline costs can be easily controlled. Rene-
opportunities. Business unit-sponsored systems eventu-
gotiate vendor contracts, reexamine service levels, man-
ally become the responsibility of IT, increasing the cost of
age assets effectively, consolidate servers, sunset older
support and maintenance (there are those baseline costs
applications, maintain a solid enterprise architecture, and
again). Cultural biases in business units may conflict with
practice good project and resource management. By so
overall strategic goals, increasing costs and resulting in
doing you can lower the percentage of the IT budget al-
the destabilization of information and knowledge. This is
located to baseline costs and keep them in line, avoiding
just as important for small companies as well as large;

65
fundamental business decision-making is driven by solid
information, and if we don’t have it we can’t do it.
3: Understand long-term
application costs
As a general rule, ongoing application costs are about 40
percent to 60 percent of the original development cost
for each year in an application’s life cycle. Sound like
a lot? These are the costs associated with application
support, maintenance, operations, software licenses,
infrastructure, and allocated help desk and operational
staff. Controlling these ongoing costs is critical; as a com-
ponent of baseline costs, they’re necessary evils. Collect
and maintain information about all new development work
underway throughout the entire enterprise and actively
participate in all projects as a value-added business
partner. Communicate effectively and relentlessly; report
to senior management anticipated costs both at the start
of projects and at appropriate intervals thereafter. Don’t
forget to maintain a historical record of all costs.
4: Understand IT cost
estimation truths
How good an estimator of project costs are you? I’m
sorry to disappoint you, but no matter how good you think
you are, you’re not that good. None of us is; your crystal
ball is just as cloudy as anyone else’s. This is the single
biggest reason IT projects have such a high failure rate.
Remember: The cost of IT initiatives will typically ex-
ceed original estimates by an average of 100 percent.
Institutional knowledge is lacking as to the result of major in-
titiatives, the advice and counsel of IT is routinely omitted or
ignored, and business process change relies too heavily on
IT ownership of those business processes. How often have
you been called upon to estimate, if not virtually guarantee,
a project cost before the scope has been fully defined?
As an IT professional, whatever your role on a project,
you must provide business managers with parameters
for setting funding expectations and force those busi-
ness managers to explain why their assumptions are
valid. If you’re an IT manager, track all major development
efforts throughout the enterprise and regardless of your
role, participate in the creation of a knowledge base of
maintenance and support costs to drive future verifiable
and credible estimation. Don’t underestimate the future
costs of maintenance and support and whatever you do,
don’t make the classic cardinal error: Do not, under any
circumstances, pad budgets in anticipation of an under-
estimation. Keep track of project costs as the project
unfolds and communicate, immediately and vociferously,
the instant you detect even the potential for an overrun.
5: Leverage current system
investments
Applications, purchased software, networks, infra-
structure, and any IT investment should all be regularly
reviewed, at least on an annual basis, to ensure maximum
value is being extracted and that original ROI goals are
being met. Start with the original requirements and review
them to ensure return on investment goals were deliv-
ered. Examine changes in the business and review new
requests to determine whether they fit with the exist-
ing systems. Consider business reengineering. Review
embedded processes to determine whether they’re
consistent with new organizational models and make
changes where necessary. Review vendor and product
features, making sure they still fit within the organization.
Enterprise architecture is organic; it’s not once and done.
It changes over time. Keeping up with those changes al-
lows for adjustments either at the periphery or by making
modifications to existing components. This is an effective
way to control overall costs.
6: Implement short-term
cost cutting measures
Often we can control costs by putting in place tactical
solutions. Short-term thinking can also be an effective
tool in project cost estimation, in that it focuses us on the
details. Getting from New York to Tokyo involves a fairly
long flight, but we can’t forget that we still have to figure
out how we’re going to get to the airport to begin with.
66
Try to postpone capital purchases as long as possible.
This may not only provide time to negotiate better costs,
but an idea for a less expensive solution may present
itself after the project has begun. Always control project
scope. Come to agreement as quickly as possible with
business unit customers and sponsors as to the overall proj-
ect scope and put that in writing. Have an effective change
management process for the inevitable “just one more
thing” discussions, which will limit or postpone until after
project delivery the single biggest reason for cost overruns.
Try to control human resource spending. There are only
two reasons to use external consultants--to fill a knowl-
edge gap (we don’t know how to do something) and to fill
a resource gap (we have too few to complete the project
on time). Negotiate the best possible rates and where
possible, use fixed-price agreements rather than T&M
(time and materials).
7: Implement long-term
cost cutting measures
Be tactical, but don’t forget to be strategic at the same
time. Make sure there’s an enterprise architecture; it’s
hard to put the puzzle together when you have no picture
on the front of the box to go by. Eliminate duplicate
processes and systems, eliminating unnecessary costs
in the process. Reprioritize and rejustify all IT projects
on a regular basis. Just because something made sense
in January doesn’t mean it still does in August, so why
waste the budget? And outsource selectively. These are
the costs that typically are the most controllable yet too
often lead to the highest cost overruns.
8: Implement pricing and
chargeback mechanisms
I once worked for a CIO at a Fortune 500 company who
decided an internal chargeback process was needed to
make business units more accountable for technology
costs. He successfully implemented the new approach
and was credited with saving the corporation many mil-
lions of dollars. He was also fired, because this approach
is the one most fraught with political peril.
67
Absent a chargeback mechanism, business units tend to
look upon IT as a giant free toystore. Put one in place and
those same business units feel free to go to the outside
to get more competitive technology pricing, and IT loses
control and becomes marginalized.
If your company is going to consider this, there are ways
to achieve both goals: making the business units ac-
countable and maintaining central technology architec-
tural control. Internal IT must be competitlve with external
service providers. Periodic benchmarking exercises are
key. Don’t underestimate the substantial resources needed
to effectively administer chargeback mechanisms to ensure
that business units have all the information they need and
no one feels at a disadvantage. IT must have a clear under-
standing of all costs and manage the demand appropriately.
Use client satisfaction surveys and service level agreements
(a good idea no matter what the circumstances) and always
show a balance between costs and benefits.
9: Use governance to drive IT
investment decisions
Too many organizations fly blind, with little synergy
between IT and the business. In most organizations, IT is a
discretionary expense center; there’s a fundamental frame-
work (baseline costs again) but most, if not all, of what’s
required beyond that isn’t necessarily mission critical.
Enlightened organizations understand that IT is a value-
added strategic business partner, and a
successful collaboration between IT and the business
drives significantly increased stakeholder value. Establish,
or if one exists become a participant of, a strategy council
to examine enterprise-level issues of strategy, politics,
priorities, and funding. Set up a business council to define
priorities, oversee projects, and measure (and
communicate) project success across business units.
This group must, of course, have the courage to cancel
projects when that becomes necessary; not everything
that starts must finish. Put together a technical council
to develop guidelines and principles for technology
standards and practices. These are three very different
organizational constructs, and while there may be some
overlap in terms of participation, the mission of each is
mutually exclusive.

10: Quantify the value/benefit

proposition for IT investments
Why do we do what we do? That’s not an existential or
rhetorical question. IT exists to provide value, to
participate in the achievement of organizational strategic
goals. How can we prove we’ve done so? Just because
we’ve built a thing, that doesn’t mean much. Does the
thing work? Does the thing provide value? Is that value
measurable and consistent with the corporate mission?

Some quantifiable benefits of IT work can be improved

operating efficiencies, enhanced personal productivity,
enhanced decision quality, and/or enabling or supporting
organizational strategic initiatives. What’s most critical
is to ensure the credibility of any measurements used to
justify IT investments and provide after-the-fact
valuations. You may be working on a project that will
reduce a process from five person-days’ worth of work to
two. Does that mean three people are going to be fired,
with the resulting compensation cost saving attributable
to your project? Probably not. Those folks will most likely
be reassigned, so don’t take credit for expense reductions
that aren’t going to happen.

68
Top five reasons organizations fail at
project management
Generally speaking, all companies and organizations
are trying to get better at project management. (In other
words, there aren’t any organizations that are purposely
trying to get worse at project management.) Though they
may not be able to articulate it, organizations recognize
that there is value associated with being able to manage
projects more effectively.
Why then, are so many organizations still so bad at project
management? What is keeping most organizations from
being able to effectively manage projects? I have pondered
this on many consulting and training engagements and
I have ranked my top five reasons below. See if you can
pick out the reasons why your organization falls short in
implementing good project management discipline.
5. Senior managers think that
project management is a
software tool
When you discuss project management with some
managers, they initially think you are trying to implement a
tool that allows you to be a better project manager.
Actually, if it were a tool, you might have more luck
convincing them to do it. Even though some aspects of
project management, like the creation and management
of the workplan, may utilize a tool, that is not where the
value of project management is. Instead, project
management is about skills and discipline. It’s about
applying proactive processes and best practices. It’s
about using common and understood templates. Don’t
get me wrong–tools have their place. However, software
tools are not the answer .
4. Organizations don’t value
the upfront investment of time
Many people consider themselves to be “doers.” Organi-
zations can be that way as well. If you’re going to be good
at project management, you have to understand that the
69
upfront planning process has value. You need to know that
if you plan the project well (in other words, if you know what
you’re doing before you start), you’ll be able to manage the
work more effectively. I have seen organizations that say
they want to apply good project management, but then are
unwilling to invest the time required. No one wants to take
the time to plan. Instead, everyone wants to start executing
immediately and then redo all the work later to get it right.
3. You may have been burned
in the past
A common criticism of project management methodol-
ogy is that it is cumbersome, paper intensive, and takes
too much focus away from the work at hand. Sometimes
this is a legitimate concern, caused by not scaling the
methodology appropriately to the size of your project.
However, project management was not the problem. The
problem was a misguided attempt at implementation of
project management. If you implement project manage-
ment methodology right, the results will be outstanding.
2. Your organization is not
committed
Many organizations say they want good project man-
agement, but do the actions back up the words? For
instance, the first time you try to define the work, does
everyone say “just get going”? If you try to enforce scope
change management, does your manager say “just do
the work”? Does your sponsor say you are wasting time
identifying risks? This disconnect is very common. The
words say one thing, but the actions say another.
1. Organizations don’t know how
to implement culture change
Most organizations don’t know how to manage culture
change in general and project management in particular.
You can’t just train people and turn them loose. You can’t
just buy MS Project and turn people loose. You have to
have a long-term, multi-faceted approach to managing
culture change. It takes hard work and resources. Most
organizations aren’t committed to focus on the culture
change long-term, and they don’t want to spend any
resources to do it. Is it any wonder then, that six months
later, project management deployment ends up in the
trash pile of culture change initiatives that have all failed in
the past?

70
Beware of when “completed” activities
aren’t really completed
One of the primary responsibilities of a project manager additional follow-up work. This may be a case of
is to assign work to team members and then monitor the the team member trying to get away with
work to see that it is completed on schedule. the fact that the deadline date was missed.
However, it may also be a legitimate misunder-
It’s important that team members understand the work to
standing of what it means to be complete. Just
be completed, the estimated effort, the estimated cost (if
as with the prior example, the first time it occurs
applicable) and the estimated completion date. It’s very
you may have an opportunity for coaching. If it
possible that a team member will not agree with these es-
happens again, it may be the sign of something
timates. And he or she may have a legitimate concern. No
more serious.
one likes to be held accountable for estimates on some-
thing in which they didn’t have a chance to provide input. To avoid this problem, make sure that there is an approval
process for all major deliverables, and that the workplan
I tried to acknowledge this concern by always giving the
leaves time for the approval process and for rework based
team members a chance to validate that the estimates
on feedback. Then there is no question that the deliver-
were reasonable. If the team member didn’t speak up, I
able is completed, because it has either been approved or
assumed the estimates were valid.
it hasn’t. The team member can no longer hide a partially
After you assign the work, you need to monitor the work completed deliverable, and there can be no misunder-
to make sure it’s completed within expectations. There standing as to whether the deadline date referred to
may be times when you encounter a situation where the completing the draft or having the deliverable finalized
team member says that an activity is complete when in and approved.
reality it isn’t quite done. This can happen for the
following reasons:

The activity should have been completed and

the team member believes he needs just a short
amount of time to complete it. He might say it’s
complete and then finish it up quickly, rather than
deal with the consequences of the activity being
late. This is a problem. The first time it occurs,
you may need to provide some coaching. If it
happens again, you might need to deal with the
situation as the start of a performance problem.

A deliverable is “completed” in draft form but not

finalized and approved. The team member may
say the work is complete, but when you check
the deliverable you find it’s incomplete or needs

71
See effect of dependent risk by using
a decision tree
Most of the risks project managers face are independent fill the entire order) and risk B will also come true (i.e., the
of other risks. These types of risks are easier to identify backup vendor goes on strike). That would be the worst
and easier to manage. However, there are times when case scenario for you. The total risk is calculated by mul-
risks are connected. That is, it’s possible that certain risks tiplying the individual risks. Since there is a 20% chance
will only appear as a result of actions taken as a result of of risk A, and a 25% chance of risk B, the probability that
managing another risk. That’s where the decision tree is both risks will occur is 5% (.20 * .25).
used. A decision tree is a technique for determining the
You can use risk trees to come up with financial implica-
overall risk associated with a series of related risks.
tions as well. Let’s look at the generic decision tree in
For example, let’s say your project needs to place a large Figure A, which is slightly more complex.
equipment order. You think there
is a 20% risk that your primary Figure A
hardware supplier may not be able
to provide all the equipment you
need for a large order in a timely
manner. This could be risk A. As a
part of the risk response plan, you
decide to talk to a second vendor
to see if they can help fulfill the
equipment order on short notice.
The vendor normally has the
equipment in stock. However, you
also discover that there is a 25%
possibility that there may be a
disruption in their plant because of
a potential strike. This is risk B.

Do you see how the two risks

are related? Risk A is the primary
project risk. If you can successfully manage risk A, there
will be no reason to work with the second vendor and,
therefore, risk B will never enter into the project. If risk A
comes true, your risk plan will need to deal with a second
risk B.
What you really want to know is what the chance is that
risk A will come true (i.e., your primary vendor cannot ful-
This decision tree shows two risks: A and B. Risk A has
two outcomes; outcome 1 is 20% likely to occur, and
outcome 2 is 80% likely to occur. The monetary value of
risk A is $10,000. If outcome 1 occurs, a second risk B is
introduced, and there are three likely outcomes, 1.1, 1.2,
and 1.3. The monetary value of risk B is $30,000. Using
the decision tree, you see that the financial risks of the
various outcomes are as follows:

72
 Outcome 1.1 has a financial risk of $9,500
($10,000 * .20) + ($30,000 * .25).

Outcome 1.2 has a financial risk of $23,000

($10,000 * .20) + ($30,000 * .70).

Outcome 1.3 has a financial risk of $3,500

($10,000 * .20) + ($30,000 * .05).

Outcome 2 has a financial risk of $8,000

($10,000 * .80).

So you should try to achieve outcome 1.3 because it has

the smallest financial risk impact. If you don’t think you
can achieve outcome 1.3 (and there is only a 1% chance
you can (.20 * .05)), you should try for outcome 2. There is
an 80% chance you can hit outcome 2.

As you see, this process can get complicated. Fortunate-

ly, most project risks are independent of each other. But
when you discover that one risk leads to another depen-
dent risk (and perhaps more dependent risks), a decision
tree can help you determine the probability and impact of
each risk combination.

73
Apply work breakdown structure techniques
to organize a program
Most of have you have used a work breakdown could be further broken down into databases, web, batch
structure (WBS) to break large units of work into the processes and core application logic.
smaller activities. These smaller activities end up being
4. Define each deliverable/work
used as the basis for your project schedule. This tech-
product to be a project.
nique is also called “decomposition” - that is, breaking
At this point you have broken a large piece of work down
down larger entities into more and more granular compo-
into a more manageable group of deliverables and work
nents or “breaking big rocks into small rocks.”
components. The trick now is to define individual projects to

You can apply this same logic when structuring very large create each major deliverable and each work component.

projects. If you have work that’s too large to manage as

5. Estimate the work required for
one unique project, you can break the work up into a set
each project.
of smaller projects. You can then establish a program to
You should be able to determine, at a high level, the work
coordinate the individual projects so that all of the busi-
required to complete each project. This may not be instantly
ness objectives and business value is achieved.
obvious and might require some upfront analysis and

You can use this simple model to define the underlying research. However, you must have some idea as to the

projects within the program.
1. Define the overall scope
of the program.
This is the first step. You can’t define the underlying
projects unless you understand the total amount of work
required. The program scope defines the totality of work.
Anything not in the program scope would not be consid-
ered as a part of the program.
2. Break the overall scope into the
underlying deliverables.
This is where the work breakdown structure technique
comes in. In this case we are actually creating a model
called the Program Work Breakdown Structure (PWBS).
3. Break down large deliverables
into smaller work products.
Some deliverables may still be too large to create in one
unique project. In this case, you’ll need to break the large
deliverable into smaller work products. These can also be
called sub-deliverables. For instance, a large IT system
estimated effort, cost, and duration of each project before
you can proceed to the next step. This will not be extremely
accurate, but hopefully you can get these estimates of effort
and cost to around plus or minus 35%-50%.
6. Put the projects in sequence.
Now that you have the projects identified and estimated,
you can create a high-level project Gantt chart. You can
determine which projects need to be executed sequen-
tially and which ones can be executed in parallel. You can
also estimate the overall duration of the program by lay-
ing out the sequence of the underlying projects. Likewise
you can create an overall project budget by adding up
the estimated costs for all of the projects.
The days of the mega-project are over. It’s better to break
down huge initiatives into a group of smaller projects,
and then coordinate and manage the multitude of smaller
projects under an overall program. The technique above
gives you guidance on how to define what these smaller
projects look like.

74
Supervise larger projects with a schedule
management plan
As your project grows larger, your project management
processes need to become more rigorous and structured.
(The reverse is also true: Processes should be simpler for
smaller projects.)
Normally, the process used to update and manage a
project schedule is pretty clear. For example, you might
receive updates from your staff every Friday and assign
new duties each Monday.
However, such a simple process may not be rigorous
enough for a very large project. The project manager on a
larger project may need to plan ahead to understand and
communicate how he or she will manage the schedule.
The document used to define this is a schedule
management plan.
A schedule management plan is part of the overall project
management plan, which includes all of the documents the
project manager needs to manage the project successfully.
Here are some specifics that a schedule management
plan can define for a project:
Roles and responsibilities: Describe different
roles, and define their responsibilities for schedule
management.
Schedule owner: This is likely the project
manager. It would be rare that a formal project
manager would not own the schedule.
Update responsibilities: Normally the project
manager is in charge of updating the plan, but
things can be more complex on larger projects.
For example, a project administrator might make
the initial schedule updates based on the project
status reports and then send the draft to the
project manager for final updates. Team
75
members can also update the status of their as-
signed activities, leaving the project manager to
perform a final analysis after those updates.
Access to the plan: Schedules are typically not
kept confidential, so anyone can access and
read them. However, if you have reasons to
keep the schedule more secure, you can specify
the access. For example, you might not want
contractors to read it.
Update frequency: Describe the timing of sched-
ule updates. In many projects, users update the
schedule on the morning of the first workday.
While you should update the schedule at least
weekly, you may also want to do so more often.
Progress feedback: Describe how you want team
members to provide schedule feedback. Such
feedback often comes in the form of a team
member status report, but it may also come dur-
ing meetings or through e-mail. Use this section
to define how you want to receive this feedback
to minimize confusion with team members.
Schedule change review and approval: Define
the process required to evaluate and approve
proposed schedule changes. You should also
describe who has the authority to accept and ap-
prove changes to the schedule. Keep in mind that
the approval process doesn’t include internal ac-
tivity deadlines; instead, it applies to changes in
the overall project deadline. The project manager
may have some discretion to extend the deadline
date by some number of days or weeks, but after
a certain threshold, some formal body may need
to approve the change.
 Tools: Describe any scheduling tools that the
team will use on this project, who has access
to the tools, and what team members can do
with the tools (e.g., read the schedule, update
schedule, etc.)

Reports: Define the types and names of reports

you’re using to manage the project, who creates
them, who receives them, the frequency of the
reports, etc.

Schedule integration: While projects normally

keep independent schedules, the master sched-
ule can also serve as a roll-up of other underlying
schedules. You could also integrate the schedule
with a higher level program or portfolio schedule.

All of these suggested items are components you should

think about and define when beginning a larger project.
Once you’ve created the schedule management plan,
don’t forget to communicate the information to all inter-
ested stakeholders — and make sure you follow the plan
throughout the duration of the project

76
Look at four ways to set precedence
relationships in your schedule
Part of the process of building a project schedule involves
breaking down the work into smaller activities (the Work
Breakdown Structure) and then sequencing the activities.
When you sequence the activities you should make
sure that every activity is related to at least one other
activity. In many cases, the relationships will involve two
or more activities.
There are a couple of ways to represent these relation-
ships. Perhaps the most common technique is called
This finish-to-start relationship would say that
we must create the Project Charter before we
obtain Project Charter approval from the Project
Sponsor.
Start-to-Finish
Start-to-finish means that Activity A must start before
Activity B can finish. This is a very rare relationship.
Example: Let’s assume that you want to fertilize your garden,

Precedence Diagramming Method (PDM). (This technique but the plants must all be wet when the fertilizer is applied.

is sometimes called Activity on Node (AON).) In the PDM

Activity A is to “fertilize the garden.”
technique, the activities themselves are placed in boxes
Activity B is to “water the garden.”
and the boxes are connected with arrows that show the
precedence relationship. The start-to-finish relationship says we need to
start watering the garden (activity B) first to get
The most common precedence relationship is when one
the plants wet. This activity must continue until
activity cannot start until another activity has finished.
the fertilizing starts (activity A). This will ensure
In most schedules this is the relationship that exists in
the plants remain wet until the fertilizer is ready
almost all (if not all) cases. This is referred to as a Finish-
to be applied. Note that you can start watering at
to-Start relationship. However, there are three other ways
any time and you can finish fertilizing at any time.
that one or more activities can be related to another one.
The relationship only ties the start of activity A to
All four are described below.
the completion of activity B.

First, let’s assume we have two activities - “A” and “B”. It
does not matter what the exact activities are. It only
matters that there is a relationship between them. There
are four possible relationships.
Finish-to-Start
This means that Activity B cannot start until Activity A has
completed. This is by far the most common relationship
between multiple activities. In most schedules, all
relationships will be finish-to-start. Example:
Start-to-Start
This means Activity A must start before Activity B can start.
Example: Assume that you are having your walls painted
in one room and wallpaper is being hung in another room.
You want to minimize the total disruption and so you want
to make sure both activities happen at the same time.
Activity A is “Paint the walls.”
Activity B is “Hang the wallpaper.”

The wallpaper hangers may be ready to go

Activity A is “Create the Project Charter.”
(activity B). However, the start-to-start relation-
Activity B is “Obtain Project Charter approval
ship says that they cannot start until the painting
from the Project Sponsor.”
starts (activity A). This relationship is based on

77
 the activity start times. The end times of each
activity are not related and, in fact, one activity
could end at a much later time than the other.

Finish-to-Finish
This means Activity A must finish before Activity B can finish.

Example: Assume you’re cooking dinner and you want the

turkey to finish cooking before the potatoes.

Activity A is “Cook turkey.”

Activity B is “Cook potatoes.”

The finish-to-finish relationship says that the

turkey must finish cooking (activity A) before the
potatoes finish cooking (activity B). This relation-
ship is based on the end times. They can each
start whenever they need to, as long as they
finish in this order.

78
Create a risk contingency budget using
Expected Monetary Value
Risk management is the process of
identifying and proactively respond-
ing to project risks. Generally (but not
always) you will look for ways to elimi-
nate risks or to minimize the impact of
a risk if it occurs.

However, what if you’re unsuccessful

in preventing some risks? In that case,
the risk will actually occur and cause ask for that level of risk contingency budget. The only
some type of problem for your project. If the risk occurs, reason you would need that much money is if every risk
there may be some monetary impact on your project. occurred. Remember that the objective of risk manage-
ment is to make sure that the risks do not impact your
A risk contingency budget can be established to prepare
project. Therefore, you would expect that you will be able
in advance for the possibility that some risks will not be
to successfully manage most, if not all, of these risks.
managed successfully. The risk contingency budget will
The risk contingency budget should reflect the potential
contain funds that can be tapped so that your project
impact of the risk as well as the likelihood that the risk will
doesn’t go over budget.
occur. This is reflected in the last column.
The question is — how do you know how much money to
Notice the total contingency request for this project is
place into the risk contingency budget account? You can
$33,500, which could be added to your budget as risk
use Expected Monetary Value (EVM) as a technique to
contingency. If risk C and F actually occurred, you would
quantify the risk into budget terms.
be able to tap the contingency budget for relief. However,
We will need two numbers for each risk: you see that if risk D actually occurred, the risk contingen-

P — probability that the risk will occur.
I — the impact to the project if the risk occurs. (This can
be broken down further into the cost impact and the
schedule impact, but let’s just consider a cost
contingency budget for now.)
If you use this technique for all of your risks, you can ask for
a risk contingency budget to cover the impact to your proj-
ect if one or more of the risks occur. For example, let’s say
that you have identified six risks to your project, as follows:
Based on the identification of these six risks, the potential
impact to your project is $118,000. However, you can’t
cy budget still might not be enough to protect you from
the impact. Risk D only has a 10% chance of occurring,
so the project team must really focus on this risk to make
sure that it is managed successfully. Even if it cannot be
totally managed, hopefully its impact on the project will be
lessoned through proactive risk management.
The risk contingency budget works well when there are
a number of risks involved. The more risks the team
identifies, the more the overall budget risk is spread out
between the risks. The EVM technique provides a formula
for determining the right amount of budget to apply to the
risk contingency budget.

79
Use a Fishbone Diagram to attack
complex problems
Problems arise on many projects. A proac-
tive project manager should have a set of Figure A
problem resolution techniques that can be
applied in different instances. One tech-
nique for analyzing complex problems that
appear to have many interrelated causes
is called a “cause and effect” diagram.
Because of its shape, this technique is also
called a Fishbone Diagram. (Another name
Figure B
you might hear for this technique is an
Ishikawa Diagram. This is named for Profes-
sor Kaoru Ishikawa, a Japanese professor
who pioneered the diagram in 1943.) Some
benefits of a Fishbone Diagram include:

It allows various categories of

causes to be explored.

It encourages creativity through a

brainstorming process.
It provides a visual image of the problem and
potential categories of causes.
The following description and examples show how the
problem-solving technique works.
First, describe the problem on the far right side of the
diagram. This may be the actual problem or it may be a
symptom — at this point you’re not exactly sure.
Draw a long horizontal arrow pointing to the box. This
arrow will serve as the backbone from which further major
and minor causes will be categorized and related. (See
Figure A.)
Identify potential causes and group them into major
categories along the “bones” of the Fishbone Diagram.
You should brainstorm to identify the major categories; at
this point, you shouldn’t be concerned if there’s disagree-
ment about whether a category holds the potential cause
— just put them all up. Make sure to leave enough space
between the major categories on the diagram so that you
can add minor detailed causes in later. (See Figure B.)
Continue to brainstorm the causes by looking at more
detailed explanations for each of the major cause catego-
ries identified above. The team should ask whether each
category is a cause, or if it is a symptom. If it’s a symp-
tom, try to identify the more detailed causes on slanted
lines that hook up to the appropriate major category lines.
(See Figure C.)
Sometimes, the detailed causes will have other, more
granular causes coming off of them. If so, connect ad-
ditional lines to the detailed lines. Three levels of detail is
usually the practical limit for this diagram.

80
When you finish brainstorming major causes/symptoms
and more detailed causes and symptoms, the team can
begin analyzing the information. Evaluate each major
cause and the potential detailed causes associated with
it. Remember that the original list was compiled by brain-
storming where all ideas are included. Now, you must
determine which items seem more likely to be the cause
(or one of the causes). Circle the items that are most likely
Figure C
81
and need to be investigated further.
If there’s not an obvious consensus on the top areas to
investigate, use some sort of voting system to formally
narrow down the top choices with the biggest chance
of success. For each item circled, discuss how the item
impacts the problem.
Once you circle the causes that appear to be the most
likely, you should create an action
plan for attaching these causes.
This will most likely involve some
high-level actions and assigning
the cause to a team member to be
analyzed outside of the meeting.
Remember that this technique is
used for complex problems with
multiple causes and allows you to
identify potential causes for the
problem and determine which ones
are most likely to be resolved.
A primer on projects, programs, and portfolios
Tom Mochal answers a question about project manage-
ment terminology from a TechRepublic member.
Question
I have worked at companies where a program manager
was assigned to manage all major development. In these
situations, the project manager had little authority and
was often relegated to administrative duties, tracking, and
reporting. How does this compare with your definition of
project management and the role of a project manager?
Why doesn’t the literature spend more time describing the
role of the program manager?-Dan
Answer
Your question gets at the heart of the relationship be-
tween projects, programs, and portfolios. Although
companies may describe these terms differently, I am
going to describe what I believe is the most common use,
which is also the relationship that I’ve seen in companies
where I have worked.
In general, you can divide all the work of a corporation
into projects (large and small) and support (ongoing op-
erations). Administration may be considered separately or
as a part of support. For the purposes of this discussion, I
am focusing on projects.
Projects are how all new work gets done, includ-
ing new enhancements. Projects are unique in
that they have a beginning and an end and have
specific objectives and deliverables.
Programs are used to categorize huge work ef-
forts into a smaller set of related projects, some
of which are executed sequentially while others
are executed in parallel.
Portfolios are a collection of related and unre-
lated programs and projects. The person who
manages a portfolio might be called a director or
a vice president, since the job typically involves
the overall management of the work, people,
budget, vendors, etc., many times on behalf of a
department or division.
This is all complicated because the terms and roles might
mean different things at your company. Consider the
project manager role. The Project Management Institute
actually defines five major types of project managers,
based on the type of organization and the type of project
being executed.
Each type has a different level of authority and
responsibility in the organization. Each type is also
related differently with a different set of functional, or
administrative, managers.
At your company (and others), the project manager may,
in fact, be seen as more of a coordinator and have few
real responsibilities other than administrative. You may
use the program manager role as the first one with real
authority and project management responsibility.
You may also use the term program management to de-
fine the level where you actually control budgets and staff.
In other companies, those could all be the responsibilities
of a strong project manager.
Projects
All that being said, I think you will find plenty of literature
filled with information on project management and the role
of a project manager. The key is to see how the information
maps into your organization.
It sounds as if a project manager in your organization is
more of a coordinator. The role that you consider to be a
program manager actually maps into the traditional
project manager role that you read about. So, for
instance, when you read my columns on project
82
management, you may need to mentally translate project
management issues into your role of program management.

Programs
There is not nearly as much information on program
management because typically a program is defined as
an umbrella organization over a group of related projects.
Let’s take an example of a program to send an astronaut
to the moon.

The moon-landing program is made up of dozens (or

hundreds) of projects dealing with all the specific work
required to land a human on the moon over a seven-year
time frame. No work gets delivered at the program level.
All the work is done in the underlying projects.

The program is there to help set overall direction, help

start new projects, make sure the projects are progress-
ing as they should, etc. But all the action (hence all the
literature) is still focused on the project.

Portfolios
Portfolios are similar to programs in that they encompass
a set of projects, but they are also much broader. A
portfolio will typically be the umbrella structure over a
group of related and unrelated projects.

The portfolio may also contain support groups. Usually,

a portfolio encompasses all the work associated with a
specific company business unit or a specific technol-
ogy. The person in charge of the portfolio is usually a
functional manager, reporting upward in the company’s
management hierarchy.

However, again, work is not done at the portfolio level.

Instead, the work is done on the projects that are within
the portfolio.

83
Four tips for using metrics on your project
Identifying, gathering, and leveraging the right mix of met-
rics is a way to gain better control of your large project. The
value can be quantified in a number of areas including:
Improved performance of the overall project
fulfillment and delivery process
Improved estimating for future projects
leveraged for improvement. Some metrics are just prohibi-
tively expensive to collect. The cost to collect each metric
must be balanced against the potential benefit that will be
gained. Start by gathering metrics that your organization
requires. Then add metrics that have the lowest cost and ef-
fort to collect and can provide the highest potential benefit.

Validation of duration, cost, effort and quality

Make sure your metrics tell
objectives for the project
a complete story
The problem with many metrics is that they’re reported in a
Identification and communication of best
way that doesn’t tell a complete story. The project manager
practices
and project team may know what a given metric is telling
Improved client satisfaction them, but other people accessing the information may not.
In general, metrics provide a more factual and quantitative
One way to help is to always report the metric along
basis for understanding how you are doing and the things
with the target. For instance, if you report your current
that can be done better. Without at least some basic met-
expenditures to date, also include your expected expen-
ric information, all discussions on performance and im-
ditures at this point in the project. If you report that your
provement are based on anecdotal evidence, perceptions,
project has spent $100,000 so far and your total budget
and guesses. Collect metrics, even if they are imperfect
is $150,000, the reader still doesn’t have the context to
and imprecise. They still provide a better foundation than
know whether this is a good or bad situation. Sure you’re
recollections, perceptions and guesses.
under budget, but the work is not complete either. The

Collect the metrics you’ll use better way to report this information is to state that you
have spent $100,000 to date and that according to your
You don’t want to collect metrics just for the sake of col-
estimate you should have spent $110,000 at this point in
lecting them. Of course, you need to collect any metrics
the project. If the trend continued, you estimate the final
that are mandatory for your organization. In addition, you
cost of the project to be $135,000 versus your budget of
should collect any other metrics that are needed by your
$150,000. If you report the metrics with this context, your
particular project. However, if you don’t have a purpose for
readers can understand what the numbers are saying.
the metrics, or if your project isn’t long enough that you can
really leverage the information, these customized project
Train your team in the
specific metrics are not worth collecting for your project. purpose and value of metrics
The general definition of “metrics” is not always obvious.
Make sure the value of collecting
The project manager may be trying to create a metrics
a metric is worth the cost
program for a large project, while the project team doesn’t
Just as there is some cost associated with most project
make the connection between gathering metrics and the
management activities, there’s a cost to collecting and
business value received. This disconnect may affect the
managing a metrics process. Some metrics are interest-
client as well. The project manager should take the time
ing, but don’t provide the type of information that can be

84
to explain why metrics are needed and how the informa-
tion collected will help drive improvements. Likewise,
the team should understand how to look for metrics that
will provide an indication as to the state of a process or
a deliverable. Educating the team and the client will help
the project manager obtain better metrics with less work
effort and less pushback.

85
Manage project time requirements
with these methods
One of the most common questions I hear from project
managers is: How do I determine how long a project
should take?
Many project managers use the old-fashioned gut check
method, in which they rely on past experiences to guess
how long it will take to complete a task. While this method
may occasionally work for smaller projects, it becomes
more difficult to accurately execute as the project grows
in size and complexity.
The following methods can guide you in determining your
project schedules with a higher degree of accuracy and
help your organization efficiently plan and track projects.
Activity definition
Activity definition is when you break down a project into
the individual tasks that are necessary to produce the
project’s deliverables. By using methods such as Organi-
zational Process Assets, Enterprise Environmental Fac-
tors, Work Breakdown Structure, and the Project Scope
statement in your project management plan, you can start
defining the required activities.
There are many ways to go about this, but I tend to use
process decomposition; it allows me to break down each
element of the work packages into a scheduled activity by
team member based on who is responsible for the pack-
age. At this point, you can also create the activity lists,
which help define what needs to be done later.
Activity sequencing
Activity sequencing is when you decide the order in which
the project’s activities need to be completed. Two com-
mon methods for doing activity sequencing are the Arrow
Diagramming Method and the Precedence Diagramming
Method. I find the Precedence Diagramming Method
more flexible for my projects, but I recommend that you
assess the pros and cons of both methods to see which
one works best for your projects.
Activity duration estimation
Many factors contribute to determining a project’s activity
duration; these factors may include business needs or
situations that have legal requirements.
To estimate an activity’s duration, start by using your
Project Scope statement in order to understand any
project constraints or assumptions that could impact your
estimating. You can base your estimates on similar activi-
ties that have occurred in the past (analogous estimating),
or you can estimate based on how long something typically
takes to accomplish (parametric estimating). An example of
a parametric estimate is: If it takes two weeks to build one
house, it will take six weeks to build three houses.
You can also estimate an activity’s duration by using
the Program Evaluation and Review Technique (PERT)
formula. PERT weighs the average of the pessimistic (P),
most likely (M), and optimistic (O) estimates for an
activity. For example:
PERT formula = (P+4M+O) / 6
Activity resource estimating
Once you know which tasks to complete, it’s time to
figure out: how many resources you need, when you need
the resources during the project, and how long you will
need the resources.
You shouldn’t need to do much guessing because you
can rely upon your Organizational Process Assets, expert
judgment, published existing data, or bottom-up
estimating when validating your resource requirements.
All of these methods are valid ways to put firm numbers in
place when determining your resource needs.
86
Schedule development
During schedule development, you bring together informa-
tion from activity sequencing, activity duration estimation,
and activity resource estimating to help build your project
schedule, as well as your project schedule baseline.

If there are any issues at this point in your schedule, you

can perform resource leveling or schedule compression.
Resource leveling will help you manage your resources
during periods where you may have initially found them
to be over/under committed. Schedule compression will
show you the impact of adding more resources to any
critical path items or how running tasks in parallel can
benefit the schedule.

Schedule control
While schedule control is part of the necessary Integrated
Change Control process, you must also know where
your project is at any point in time. This step will help you
define and communicate how to handle things that affect
the project’s timelines. Any changes that may impact
areas such as the schedule baseline or approved change
requests need to be handled via this process to ensure
you can track their significance on the project.

Summary
During the course of any project, you will struggle with
questions about what to do and when to do it. By taking
a more structured approach when defining and answer-
ing your questions about time management, you will put
yourself in a better position to come away with a plan that
you can explain and execute.

87
Don’t wait to address performance
problems on a project
Most project managers have had to deal with perfor- at an unacceptable quality level, or chronically misses
mance problems on a project at one point in their careers. other expectations.
Such issues are usually uncomfortable adventures for the
If a project manager believes a team member is having
project manager. This uncomfortable feeling usually has
performance problems, the first reaction should be to
two causes:
meet with the team member one-on-one. In this discus-
The project manager is usually not the functional sion, the manager can discuss his or her perceptions of
manager of the team member and therefore does the employee’s behavior and its effects on the project.
not have total authority for personnel manage- The discussion should remain fact-based, and the project
ment. manager should have a number of examples of when the
team member missed expectations.
The project manager usually doesn’t have the
right level of experience or training to effectively This discussion needs to be two-sided. One of the
deal with people problems. benefits of the first meeting is that the manager can share
concerns, and the employee has a chance to tell his or
In fact, many experienced personnel managers will tell
her side of the story.
you that dealing with performance problems are the hard-
est aspects of their job. It’s even more problematic for a You never know how these first discussions will progress.
typical project manager. Sometimes they’re difficult and don’t accomplish what
you hope. However, in many cases, the team member
The first reaction of many project managers is to ignore
agrees with the project manager and offers reasons for
a performance problem and hope that it goes away. It’s
missing expectations.
possible that the situation will take care of itself, but
unfortunately, this usually isn’t the case. Once you better understand the causes of the problems,
you may be in a better position to help fix them. For
A project manager’s second reaction is typically to recog-
instance, there may be some skill gaps that you can use
nize the problem but try to determine whether the project
training or mentoring to address. There may also be some
can still complete successfully in spite of the performance
personal problems that may require special accommoda-
problems. Again, sometimes that may be the case, but
tion on the part of the project manager.
ignoring the situation rarely works.
In many cases, the fact that a meeting is necessary will
After all, the nature of a performance problem is that a
be enough to motivate the team member to do better in
person is missing deadlines and commitments. (If the per-
the future. The meeting should end with some concrete
son were meeting end dates, the team member still might
follow-up commitments for addressing the problem. This
be causing problems — but not of a performance nature.)
could include actions from both the project manager and
Of course, people can miss a deadline for a variety of team member.
reasons, and that alone doesn’t raise the situation to the
If the project manager and team member can agree on
level of a performance problem. A “performance problem”
some follow-up actions, then you might consider the
occurs when a team member is repeatedly late, delivers

88
meeting to be a success. If you can’t agree on a common
set of follow-up activities, then further escalation up to the
functional manager may be necessary.

Managing people is one of the core responsibilities of a

project manager. It’s also one that’s uncomfortable for
many. Dealing with problem people is one of the difficult
aspects of managing team members.

One of the best strategies for managing people problems

is to address them early before they escalate. If you can
successfully address a problem early, it may save you
much more aggravation and pain associated with having
to deal with a chronic problem later.

89
Master these 10 processes to sharpen your
project management skills
Small projects don’t necessarily require much knowledge
of project management or much project management
discipline. But as a project gets larger, formal processes
and techniques become essential. Different project
management methodologies organize and structure these
processes in various ways, but we’re going to focus on 10
basic areas:
1. Define the project
2. Plan the work
3. Manage the workplan
4. Manage issues
5. Manage scope
6. Manage risks
7. Manage communication
8. Manage documentation
9. Manage quality
10. Manage metrics
In general, if you can master these areas, you can suc-
ceed in most projects. You may not have to worry about
managing documentation or metrics on a small project,
but the larger your project, the more you’ll need to focus
on all 10 processes.
Notice that our list doesn’t include analysis, design,
testing, or implementation. Those who have worked on
projects probably know that they typically include analysis
and testing. However, there is a major distinction to be
made. Analysis and testing are part of the actual project
work effort (also called a project lifecycle). These phases
change depending on the project type. If you have a full
lifecycle project, you could perform the full range of analy-
sis, design, construction, testing, and implementation. On
other projects, you might do only certain components. For
example, if you were performing a research and develop-
ment project, you wouldn’t be doing implementation. If
you were performing a study, the project might end after
the analysis phase.
Do you see something missing?
Two processes are sometimes included as a part of basic
project management: people management and contract
and procurement management. People management is an
important skill for project managers, but it’s not specific
to project management. After all, any management-sub-
ordinate relationship requires people management. The
distinction is that it’s a project “manager” skill, but not
necessarily a project “management” skill.
We’ve also excluded contract and procurement manage-
ment from our list. In most organizations, project manag-
ers need to know about the management of contracts
and vendors, but they aren’t responsible for it. A legal
department and/or procurement department is usually
responsible for these disciplines.
Timing and sequencing of
the processes
Except for the first two categories — defining the project
and planning the work — the 10 major project manage-
ment areas don’t fall into a sequential path. Processes 3
through 10 can be done in any order, and in fact, are done
in a parallel and ongoing manner throughout the project.
For example, if a major problem pops up, you must use
issues management regardless of what other aspects of
project management you’re using before, during, or after
that time. Let’s take a closer look at each process
1: Define the project
As the project manager, you must make sure that the
work is properly understood and agreed to by the project
90
sponsor and key stakeholders before the project work
begins. You’ll work with the sponsor and stakeholders to
ensure that the project team and the client have common
perceptions of what the project will deliver, when it will be
complete, what it will cost, who will do the work, how the
work will be completed, and what the benefits will be.
The larger the project, the more important it is that this
information is mapped out formally and explicitly. All
projects should start with this type of upfront planning to
prevent problems caused by differing viewpoints on the
basic terms of the project. The major deliverable from this
step is the Project Definition (some companies call this a
Project Charter).
At a high level, the purpose of defining the work includes:
Understanding and gaining agreement on project
objectives, deliverables, scope, risk, cost,
approach, etc. This is the most important part of
defining the work and is where most of the time
is spent in gaining common agreement.
Determining whether the original business case
is still valid. For example, a project that requires
10,000 effort hours might make business sense.
If the more detailed definition process results
in a more refined estimate of 20,000 hours, the
project may no longer be feasible.
Making sure the resources you need are available
when you need them.
Providing a high-level baseline from which
progress can be compared and scope can be
controlled.
Gaining agreement with the client on the pro-
cesses used to manage the project.
The effort required to define the work depends on the
amount of information and the level of detail that need to
be understood and documented. The duration required to
define the work depends on the length of time necessary to
91
discover and document the information, as well as the time
required to gain agreement and approval from the client.
It may be difficult to define exactly what the final deliver-
ables look like for large and complex projects. It is also
difficult to estimate the total cost and deadline date. If
that is the case, you can break the project into smaller
projects. The projects that are done first should then be
much easier to define. The projects that are to be com-
pleted in the future can be defined in detail as they get
closer to execution.
At the end of the definition aspect, you should have a
Project Definition that defines the expectations of the
project in terms of objectives, deliverables, scope, risks,
costs, deadline, and roles. This document should be
formally approved by the project sponsor and other key
stakeholders before the project team proceeds. At times,
you can get frustrated because of the difficulty in gaining
agreement with the client on scope, timeline, and cost.
But that is exactly the reason this definition work is done
ahead of time. Think of the problems you would no doubt
encounter trying to gain agreement with the client on
scope, schedule, or cost when the work had started and
the deliverables were actually being produced.
2: Plan the work
When you define the project, you make sure that you
have an agreement with the project sponsor on what work
should be completed in this project. In this stage, you
determine how the work will be completed. This involves
building the Project Workplan. You’ll take different ap-
proaches according to the size of the project. For ex-
ample, the workplan for small projects can be built using
a project management package like Microsoft Project, a
spreadsheet, or even a piece of paper.
If you don’t have a workplan template to use as your
starting point, you can use the Work Breakdown Struc-
ture (WBS), a technique for looking at the project at a
high level and breaking the work into smaller and smaller
pieces until you can get the full picture of the work. The
entire team can collaborate on this exercise. I recommend
breaking down the work into lower levels until each re-
maining activity is less than 80 hours, and it is clear what
is required to complete the activity.
Once all of the work has been uncovered, you can se-
quence the activities and identify dependencies between
them. At this point, the WBS has been converted to a
Network Diagram.
Next, you add resources (workers) for each activity. If you
know of certain resources, you can add them by name.
If not, you can use generic names as placeholders. You
then add the effort hours and the beginning and ending
dates for each activity.
Your workplan is now ready to go. You’ll know what work
you have to complete (Project Definition) and how you’ll
get the work done (Project Workplan).
The relationship between defining
and planning the project
You may find that you can’t complete the Project Defini-
tion without starting to lay out the overall Project Work-
plan. In many cases, you’ll need to work on these two
deliverables simultaneously. As you gather information
about scope and deliverables, you’ll need to start laying
out a timeline so that you can get your hands around
estimated effort and duration. When the deliverables,
scope, assumptions, and approach are complete, you
should have enough information in the Project Workplan
to estimate the budget, effort, and duration, which you’ll
use in turn to complete the Project Definition.
3: Manage the workplan
At this point, you’ve finished defining the project and
planning the work. The major deliverables in place are
the Project Definition and Project Workplan. Some
project managers think that defining and planning the
work means that the hard part of managing the project is
behind them. That is definitely not the case.
You’ll never be a successful project manager if you don’t
keep the workplan up to date. Remember, the workplan
is only a deliverable. It describes the work that needs to
occur, the order of the work, how much effort is required,
and who is assigned, but it represents only your best
guess as to how to complete the remaining work at any
particular point in the project.
The more complex your project is, the more change is
going to be required in your workplan over time. As the
project manager, you must evaluate the workplan on an
ongoing basis (perhaps weekly) and determine the current
state of the project.
During this weekly review, you’ll update the workplan
with the current state of work that is completed and in
progress. You’ll evaluate the remaining work to see if the
project will be completed within the original effort, cost,
and duration plans. If it can, you are in good shape. If it
can’t, you must implement corrective action.
Of all of the skills of managing the project, this one is per-
haps the most fundamental. Depending on the dynamics of
your project, you may be in the position of having to con-
stantly use your experience and creativity to get the project
completed within expectations. One week, your project
may be on track. The next week, you may have work as-
signments that are late and issues that have surfaced.
If an activity on the critical path is a week late, you can’t
sit idly and allow the entire project to be a week late.
Instead, you must evaluate the resources and options
available and get the project back on track. If you’re good
at it, managing the workplan can be one of the more
challenging and rewarding aspects of project manage-
ment. If you don’t relish the detailed work that is required,
you may find it much more difficult to be successful.
4: Manage issues
An “issue” arises when a problem will impede the prog-
ress of the project and can’t be resolved by the project
manager and project team without outside help. If a major
92
problem emerges, you have no choice but to resolve it.
The only question is whether you’ll actively apply issues
management to the situation or flounder through
indecision and uncertainty about how the issue should
be resolved.
Issues management has two major components. The first
is having a process to uncover issues, determine their
impact on the project, examine alternatives, and bring in
people to make the best decision under the circumstanc-
es. This is all part of the project management procedures
that should be defined and agreed to ahead of time.
These procedures ensure that issues are recognized and
resolved as quickly as possible.
The second component of issues management is apply-
ing specific problem-solving techniques. This includes
some understanding of techniques such as Fishbone dia-
grams, Pareto charts, and root cause analysis. Having an
understanding of one or more of these techniques allows
you and your team to understand the nature and cause of
the problem, what options are available, and what alterna-
tive would be the best course of action.
One important thing that all project managers discover
is that having a process to resolve issues doesn’t mean
you’ll successfully resolve every one. Sometimes, there
are great alternatives to issues and your job is to help
discover the best one. In other instances, there is no
good resolution to a major problem. On occasion, your
final choice is to pick the solution that causes the least
harm or is the best among poor choices. Still, your issues
resolution process and your problem-solving techniques
will allow you to determine what options are available so
that you at least understand the repercussions.
5: Manage scope
Scope describes the boundaries of the project and defines
what the project will deliver, what data is needed, and
which organizations are affected. Given a set of resources
and time, an infinite number of things can be delivered.
93
Scope change management starts with scope change
definition. If the project manager hasn’t done a good job
defining scope, it will be difficult to manage scope during
the project. The purpose of scope change management
is to protect the viability of the current, approved Project
Definition. When the project was defined, certain expecta-
tions were set for what the project was going to produce
for a certain cost and in a certain timeframe. Both you
and the project sponsor have those expectations in mind
when the Project Definition is developed and approved.
During the life of a project, there may be a need for items
that are different from, or not included in, the original Proj-
ect Definition; this is to be expected. If this occurs, the
client should not expect that these items can be delivered
using the previously agreed on resource and time con-
straints. The project team will identify the new require-
ments and determine the impact to the project if the new
requirements are included. The information is then taken
to the sponsor for approval.
Remember, the sponsor is the one who approved the
funding of the work to begin with. Therefore, he or she is
the one who should approve any changes to the original
agreement. If the business value of the change is high
enough, the sponsor should approve adding the new re-
quirement to the project, as well as the incremental bud-
get and timeline needed to complete the work. Everyone
will then be in agreement and everyone’s expectations will
have been reset.
Of course, sometimes it doesn’t happen so smoothly.
Common problems include:
Scope creep. Large scope changes are easy
to spot. However, when the changes are small,
sometimes you find that you’re including them
without realizing it. Scope creep means that
you’re accepting small changes that end up hav-
ing a significant cumulative effect on the project.
You and the entire team must be diligent to
guard for all scope changes — big and small.
 End-user scope approval. The project sponsor
is the person paying for the project. However,
once the project begins, the team spends more
time with lower-level clients and end users.
Some project team members believe that scope
changes are fine if the end user approves them.
This is not the case. Unless the sponsor has
specifically delegated the approval authority,
these people can’t approve scope changes. They
can raise scope change requests, but only the
sponsor has the funding authorization to approve
incremental work.
Team members not being accountable. A
common cause of missing deadlines is that the
team members end up doing more work than
required. For example, a team member may be
asked to create a report. As he or she is creat-
ing it, the client asks for new information. The
team member tries to accommodate the client,
and the work ends up being late. This happens
when team members think that only the project
manager needs to worry about scope change
management. They need to understand that it’s
everyone’s responsibility.
The root cause of many unsuccessful projects is poor
scope change management. Defining and managing
scope effectively will increase the chances that your
project will meet expectations.
6: Manage risk
Risk refers to future conditions or circumstances that
exist outside the control of the project team and that will
have an adverse impact on the project if they occur. In
other words, whereas an issue is a current problem that
must be dealt with, a risk is a potential problem. Reactive
project managers resolve issues when they arise. Proac-
tive project managers try to identify and resolve potential
problems before they occur. This is the science and art of
risk management.
Since smaller projects usually don’t have long durations,
there is less opportunity for problems to develop. Larger
projects usually have risks lurking just over the horizon.
Risk management involves identifying all potential risks to
the project, determining how likely they are to occur, and
understanding the impact on the project if they occur.
With that information, the project team can determine
which risks should be actively managed. For example, a
risk with a high probability of occurring and a large impact
on the project should definitely be managed proactively.
On the other hand, a risk that has a high likelihood of oc-
curring but a marginal impact on the project can probably
be ignored.
Once you identify which risks you want to actively man-
age, you can invoke five general responses:
Leave it. You would leave a risk if you deter-
mined that your project would not be harmed
if the risk occurred or if there was nothing that
could be done to address the risk and you’re
willing to take the chance that it won’t occur.
Monitor the risk. In this case, you don’t proac-
tively mitigate the risk but you monitor it to see
whether it’s more or less likely to occur as time
goes on. If it looks more likely to occur later, the
team must address it at that time.
Avoid the risk: Avoiding the risk means eliminat-
ing the condition that’s causing the problem. For
example, risks associated with a particular ven-
dor might be avoided if another vendor is used.
Move the risk: In some instances, the responsi-
bility for managing a risk can be removed from
the project by assigning the risk to another entity
or third party.
Mitigate the risk: In most situations, this is the
approach to take. If a risk has been identified
and is a concern, you can develop a proactive
plan to ensure that it doesn’t occur.
94
As with scope changes, there is nothing inherently wrong stakeholders will necessarily be brief and high-level.
with having risks on a project. Clients don’t expect that a
Communication Plan
project will be risk-free. What matters is the project man-
Large initiatives, especially the kind that require organi-
agement response. If risks are identified and actively man-
zational change, must include an overall Communication
aged, the project has a much better chance of success.
Plan that takes a multifaceted approach to communica-
If risks are ignored, the project will be negatively affected
tion. The process for building this plan includes defining
when the risks turn into issues. At that time, there may be
all your stakeholders, determining what information they
fewer options for resolution without impacting the project.
need, brainstorming ways to deliver that information, and

7: Manage communication then deciding on a set of communications that cover as

Properly communicating on a project is critical for many stakeholders as possible in the most resource-

managing the clients and the shareholders. If they’re efficient manner.

not kept well informed of the project progress, there is a

Depending on the audience, the communication falls into
much greater chance of problems and difficulties due to
one of three areas.
differing expectation levels. In fact, in many cases when
conflicts arise, it’s not because of the actual problem, but Mandatory. This includes status reports, budget

because the client or manager was surprised. reports, and legal and auditing requirements.

There are two levels of communicating on projects. Informational. This is communication that

First, all projects should communicate status. Second, if provides extended information for people with a

your project is larger, more complex, or more politically need to know more. Examples include a docu-

charged, you need a higher and more sophisticated level ment library, frequently asked questions (FAQ),

of communication defined in a Communication Plan. and a project Web site that contains relevant
project information.
Status meetings and status reports
All projects need effective communication from the Marketing. This is communication designed to

project team to the project manager and from the project build enthusiasm for your project. Examples

manager to the rest of the stakeholders. Status reports include publishing success stories, building a

and status meetings need to do more than just say positive image, distributing management testi-

whether the project is on track. This is the time you com- monials, and using a project logo.

municate everything you think needs to be known about

Communication must be handled proactively by the
your project. You communicate about adherence to the
project manager and must be planned and executed with
project’s budget and schedule, accomplishments from the
a purpose in mind. If you communicate effectively and
last reporting period, planned accomplishments for the
proactively, you’ll find that the entire project runs more
next period, new risks, current issues, and current scope
smoothly and with less conflict and frustration.
change requests.

8: Manage documents
The information and presentation must be communicated
Many project managers take document management for
with the audience in mind. Therefore, you would expect
granted until they’re inundated with hundreds of docu-
that a weekly status meeting with your team would
ments. It’s better to estimate the volume of project and
include discussions at a fairly low and detailed level.
project management documentation you think the project
Status reports you send to the sponsor and management

95
will produce, establish the proper processes and rules
to organize the documentation, and then manage the
documentation during the project to ensure that it doesn’t
get out of control.
Project managers on smaller projects don’t need to give
as much thought to managing documentation. As projects
get larger, the documentation definitively needs to be
actively managed. Problems at their simplest include
documentation that gets lost or is hard to find and work
that ends up being duplicated. At its worst, document
versions get out of order, document updates get over-
posted and lost, and confusion and uncertainty reign.
This is an aspect of project management that may be
supported by a tool, such as a document repository.
However, tools can be just as confusing if proper tech-
niques aren’t used to store documents in a manner that
allows them to be easily retrieved.
Document management involves simple and complex
tasks. A simple activity, for example, is a document-naming
convention. If you have 10 people on your team and each
one submits a status report each week, it’s not long before
you have hundreds of documents. It’s easier to organize
the documents if everyone uses a common naming con-
vention. Should the name of the document start with each
person’s name? If so, then each person’s historical status
reports will sort together and be easier to find.
Or perhaps you’ll want to search for status reports from
particular points in time. In that case, the status reports
should start with the date. Then all the status reports for a
particular reporting cycle will sort together.
Another part of document management is understanding
the types of document tools you’ll use. For example, you
might define Microsoft Word as your standard docu-
ment editor. If your team is cross-functional and includes
clients, vendors, and suppliers, these types of document
management rules become more vital.
Other factors must be considered to successfully manage
documents. These include where you’ll store the docu-
ments, how they’ll be organized, access and security
rules, keywords/indexing, naming standards, version-
ing, completion status, retention/purging, backups, and
standard template formats.
9: Manage quality
Quality is represented by how close the project and
deliverables come to meeting the client’s requirements
and expectations. In other words, quality is ultimately
measured by the client.
The project team should strive to meet or exceed the cli-
ent’s requirements and expectations. Sometimes there is
a tendency to think that “quality” means the best material
and equipment and zero defects. However, in most cases,
the client doesn’t expect, and can’t afford, a perfect
solution. If there are just a few bumps in the project, the
client can still say that the project delivered to a high level
of quality.
On the other hand, a flawlessly designed, defect-free
solution that doesn’t meet the client’s needs isn’t consid-
ered high quality. The purpose of the quality management
step is to first understand the expectations of the client in
terms of quality and then put a plan and process in place
to meet or exceed those expectations.
Because quality is defined by the client, it may seem that
it is completely subjective. However, plenty about quality
can be objective. This requires first breaking down the ge-
neric term of “quality” into a number of areas that define
the characteristics of quality.
For example, you can think of a quality computer applica-
tion in terms of response time, look-and-feel, ease of un-
derstanding, level of help documentation, and absence of
defects. Once you’ve defined the more tangible character-
istics of quality, you can look at each of them to determine
how they can be measured with more objectivity.
Quality management is not an event: It is a process and
a mindset. A consistently high-quality product can’t be
96
produced by a faulty process. You need a repetitive cycle
of measuring quality and updating processes.
Collecting metrics is vital to making the quality manage-
ment process work. So, the ninth and tenth aspects of
project management, managing quality and managing
metrics, are closely tied. If you want to do a good job of
managing quality, you must measure.
When the project is initially defined, the project team must
understand the expectations of the client in terms of qual-
ity and plan the activities to meet those expectations in a
Quality Plan. The Quality Plan contains completeness and
correctness criteria so that the project team knows what
the quality expectations are.
The Quality Plan also contains the two general quality
processes: quality control and quality assurance. Qual-
ity control activities ensure the deliverables produced by
the project meet client expectations. An example of a
quality control activity is an inspection of each component
that will be used to complete a final deliverable. Quality
assurance activities ensure that the processes used to
create the deliverables are of high quality. An example of
a quality assurance technique is a checklist that contains
all of the steps that a deliverable must complete before it
reaches final acceptance.
One of the purposes of quality management is to find er-
rors and defects as early in the project as possible. There-
fore, a good quality management process will end up
taking more effort hours and cost up-front in the project.
However, focusing on quality early has a large payback
as the project progresses. For example, it is much more
efficient to spot problems with the business requirements
during the analysis phase of the project than to redo work
to add missing requirements during the product testing.
It’s also much cheaper to find a problem with, for exam-
ple, a computer chip when the chip is manufactured than
to replace it when a client brings the product in for service
after a purchase.
97
10: Manage metrics
Gathering metrics on a project is the most sophisticated
project management process and can be the hardest.
Because metrics can be difficult to define and collect,
they’re usually ignored or handled poorly. All projects
should be gathering basic metric information regard-
ing cost, effort, and cycle time. However, you must also
collect metrics that determine how well the deliverables
satisfy the client’s expectations and how well the internal
project delivery processes are working. Depending on the
results, you can undertake corrective action or process
improvement activities to make the processes more ef-
ficient and effective.
Managing metrics and managing quality are related. It
is difficult to improve the quality of your deliverables or
your processes if you’re not gathering metrics. Metrics are
used to give some indication of what the beginning state of
quality is and whether quality is increasing or decreasing.
Many metrics can be gathered on a project. The project
team should identify and collect a balanced set that
provides the most value. To determine the right metrics
for your project, you:
Identify the project success criteria in terms of
product deliverables and project execution. That
is, determine what your deliverables need to look
like for the project to be successful. Also deter-
mine how your project needs to be completed to
be considered successful-for example, budget
and deadline expectations.
Brainstorm a set of metrics that provides an
indication of the state of each success criterion.
Look for a balanced set of metrics that provides
indications of success in terms of cost, delivery,
quality, and client satisfaction.
Prioritize the potential metrics to come up with
a list that provides the most value in the most
cost-effective manner.
 Set targets to allow you to determine success.
Metrics are rarely of value alone. The value
comes in measuring where you are against a
preferred state or agreed on target.

Add collection activities to the workplan to

ensure that people are responsible for the metric
collection and analysis process.

In general, metrics management is of less value on

smaller projects because there isn’t enough time to
capture the data, analyze the results, and make appro-
priate process improvement changes. Longer projects
give you time to use a feedback loop. The most value is
gained if the metrics are used to drive improvements on
an organization-wide basis.

98
Mining project requirements - techniques to
use before and after an interview
Prepare for the interview
Choose the right business
experts
In the early stages of a project, deciding whom to inter-
view is a challenge. A broad understanding of a business
problem depends on interviewing the people who know
something about it. For that reason, don’t be shy.
Ask the project sponsor for names of the people you
should initially interview. Locate each name in an organi-
zation chart, and consider their title and functional role.
Are there people above and below them in the organiza-
tional hierarchy that you should also interview? Does the
business problem affect vendors or customers? If so, ask
the sponsor for permission to interview representatives
from these groups as well. Be mindful of politics — the
supervisor of someone you interview may feel jilted if you
decide not to interview them.
Pick the right place
As an interviewer, you have to choose a meeting place that
enables the free flow of information. Unfortunately, there
are many barriers to this flow — lack of privacy and phone
interruption are examples. If interruptions are a risk, try to
meet outside the person’s office. Consider using a corpo-
rate meeting room, or somewhere offsite. I’ve conducted
some excellent interviews over lunch in a noisy place.
If you must meet in the person’s office, ask that they
“busy” their calls. If privacy is a potential issue, make
certain no one can hear through the walls of the room
where you meet. If the interviewee has a packed meeting
schedule or supervises people, convenience or decorum
may dictate a meeting in the interviewee’s office.
Schedule the meeting
Hour-long interviews work well. Recognizing the overhead
99
of preparation and follow-up, you may think a longer
meeting is best. If you don’t feel an hour is enough time,
set up a second meeting with the interviewee. Enthusiasm
for your questions often fades as the interviewee starts to
think about his or her schedule. When you schedule the
meeting, leave enough time buffers before and after your
interview for the interviewee to travel between meetings.
Leave extra buffer at the end of an interview in case a little
time is needed to finish up.
Prepare yourself
The business problem you are trying to understand has
a domain. Prepare for an interview by learning about that
domain. You should be able to identify the domain inputs
and outputs, and understand the processes within it.
There are many sources for this understanding. Exam-
ine documentation, learn existing systems, or interview
people who can give you an overview of the process.
Early in the project, it helps to create a flowchart or
context diagram showing the entities involved in a system
domain and the nature of their involvement.
Learn the language
As business specializes, jargon develops to identify and
describe its products and processes. In order for you
to understand the interviewee, you have to understand
the language he or she will use. To become familiar with
these terms and concepts, read books that describe the
industry. Your local bookstore or library may have suitable
books, and the Web is increasingly a good source. Con-
sider asking a business expert to recommend a book —
such books are often very valuable. Mentors are probably
your most valuable resource for learning to speak the lingo.
Prepare good questions
Although you may not use all of them, come prepared
to ask good questions. Tom’s article describes “how” to
interview, but you have to prepare “what” questions to
ask. Start by asking yourself:
What is the project scope? Rely on a project
charter to provide the context for the questions
you should ask.
What is the context of the interviewee relative to
the business need or opportunity you are investi-
gating? Existing operational documentation may
provide guidance.
What am I expecting this person to know? Think
about the interviewee’s role, knowledge, perspec-
tives, and interests in the context of the project.
Ask for a second opinion
When preparing for an interview, write down the questions
you intend to ask. It may help you organize and clarify
questions. Consider asking a peer to review the ques-
tions you plan to ask. Thirty years of interviewing people
has taught me that there are rarely bad answers in an
interview, but there are plenty of bad questions. By having
someone else review your questions, you may discover
a perspective on the interview you hadn’t considered. A
second pair of eyes may also help you root out improper
questions. A peer’s suggestions may add great value to
questions you plan to ask.
Consider recording the interview
If you have only one opportunity to interview someone,
bring along a tape recorder. Travel distance, difficult
schedules, or organizational statuses are sometimes bar-
riers to conducting a follow-up interview. Be sure to ask
permission from the interviewee before you begin recording.
Be honest and indicate why you need to record the inter-
view. Plainly indicate the tape will not be shared with others.
Follow-up the interview
Review and clarify your notes
Good note taking is an important interview skill — whether
you recorded the conversation or not. If you did not tape
100
the interview, your notes contain much of what the inter-
view provided in value. If you did record the interview, your
notes probably summarize key points or identify subject
areas to explore further. Either way, review your notes as
soon as possible after the interview. Otherwise, you may
miss important themes or lose clarity on a topic.
Ask follow-up questions
It is common to have follow-up questions for the inter-
viewee, particularly if you are new to the subject area, or
the project is complex. Most people appreciate getting
a follow-up phone call to clarify a few points. When you
call, apologize for the interruption and ask if he or she
has a few minutes to answer your follow-up questions. If
they are busy, ask for a better time to call. While you can
ask the questions by e-mail, what often ensues is time-
consuming and unsatisfactory.
Summarize your notes and ask
for feedback
Ask yourself, “How do I know I understood the stated
requirements?” Even if you recorded the conversation and
listened to the tape, the interviewee may have intended
something other than what was said. In addition, the
answers to your questions may have only uncovered a
portion of the requirement you hope to define. Summarize
each of the requirements you heard. Send the interviewee
an e-mail with the requirements as an attachment. Be
sure to thank them for their time and interest in the proj-
ect. Invite them to review what you wrote and ask them to
contact you to correct the requirements.
Next steps
While preparing adequately for a requirements interview
does not guarantee success, failing to prepare puts your
interview at risk. Adequate interview follow-up improves
the quality of the requirements you uncover. Requirements
tracking refers to the process of tracking (or tracing)
requirements from the beginning of the project through
implementation. It’s a good practice for many projects
Ensure requirements are tracked
throughout a project
Requirements tracking refers to the process of tracking requirement is accounted for in subsequent project phases.
(or tracing) requirements from the beginning of the project For instance, something like the following table might do.
through implementation. It’s a good practice for many
The “X” in each box validates that each particular require-
projects – especially if you’re building something from
scratch. Requirements tracking is a good
practice for two reasons.

1. It ensures that all requirements are,

in fact, implemented in the final
solution. If you check at the end of
the project to see whether they’re
all present, it might be too late
to implement any that you forgot.
Tracking ensures that you catch any missing ment was accounted for in each phase.
requirements immediately in the lifecycle.
There are other more sophisticated way to track require-
2. It ensures that no features and functions are intro-
ments as well. If you have many requirements in a large
duced outside of the requirements. For instance,
project, you could even look for tools that will support this
if you add extra work in project design, it will be
requirements tracking process.
more obvious since you won’t be able to track the
design component back to a requirement. This If you’re going to do requirements tracking, it must be

will save you doing extra work that’s not required.
In addition, a smaller benefit is that you may be able to
track the requirement back to the source that it came
from. This will help you know the right person to talk to if
you have questions on the requirement.
Not all projects need to trace requirements. Smaller
projects typically don’t need to. If your have a set of ten
requirements for an enhancement project, for instance, it’s
probably pretty easy to validate that they’re all accounted
for throughout the project lifecycle.
The easiest way to track requirements is through a simple
Traceability Matrix. The Traceability Matrix provides a
quick glance at all of the requirements and validates
that they’re being considered throughout the rest of the
lifecycle. The simplest approach is to just validate that each
enforced throughout the lifecycle or else it doesn’t work. If
the team assigns tracking numbers to the requirements in
the Analysis Phase, but the numbers are not utilized in the
Design Phase, the whole tracking scheme will break down.
Likewise, if the Design Team follows up on the tracking, but
the requirements are not tracked to the actual construct
components, it will be difficult to track whether they’ve
been tested or not and the scheme will break down. If you
want to track requirements, you need to have a process to
track and document them throughout the project.
This tracking can be tedious, which is probably the main
reason it’s not done on more projects today. However, if
you want to make sure you’re working on the right things
throughout the project (no more and no less) then require-
ments tracking is the technique to know for sure.

101
Use gate reviews to validate that you’re ready
for the next phase of your project
In the past, it wasn’t uncommon to gain a commitment to
start a project and then never look back again. Over the
past ten years, however, it has become more common to
set up specific points in the schedule where the project
could be evaluated to ensure things are on track and to
determine whether the work should continue.
Sometimes these criteria are called exit and entry criteria
and the event is called a “gate.” The analogy is that the
project comes upon a “gate” and must get approval
before the gate can be opened for the project to proceed.
Although there will be multiple gates in a project, the
Forward looking
purpose and the nature of each is similar. This makes
the gate review similar from phase to phase and even
from project to project. Since the process is similar, these
reviews tend to be good candidates for a checklist.
Gate reviews are categorized as Quality Assurance since
they are focused more on the processes completed rather
than reviewing any specific deliverables. The specific
deliverable reviews should have been completed earlier.
Here are some of the activities in the phase gate
review meeting.
Backward looking
Deliverable approvals. You should make sure
that all of the deliverables that need approval
have, in fact, been approved. Sometimes this
final approval may even take place at the phase
gate review meeting. If the deliverables from the
prior phase are not approved, then the project
may not be ready to enter the next phase.
Budget and schedule review. The project bud-
get should be reviewed to validate where you are
within your total budget estimate. Likewise, you
should check to see if you’re on schedule and
102
take some corrective actions if you’re not.
Review project issues. You should validate that
all outstanding issues have been resolved or that
there’s a plan in place to resolve them.
Review project risks. This is a good time for a
risk control meeting. You should validate that
your prior risks are being successfully managed
or you need to revise your risk plans. You should
also look for any new risks to your project.
Validate schedule and budget estimates. You
should project out (from now until the end of the
project) to make sure your current estimates for
final spending and deadline are still valid. If they’re
not, you can update the information at this point.
Validate that business case. This is a time to
check that the original Business Case is still
valid. An increase in the project deadline or
budget may mean that the Business Case no
longer makes sense. It’s also possible that the
business value of the project has changed.
The phase gate review is a good opportunity to
cancel a project that no longer makes sense.
Check that resources are available. In many
projects, the types of resources and the skills of
the resources change from phase to phase. This
is an opportunity to validate that you still have
the resources required to complete the
remainder of the project.
Validate your sponsorship. Perhaps the interest
and commitment of the sponsor has waned
since the project started, or the sponsor has
changed. Use this time to validate the priority
 of the project with the sponsor and cancel the
project if the sponsor is no longer committed.

Once you have validated that all of the prior work is com-
plete and correct, and you have validated the commit-
ment to proceed, you should obtain a formal approval to
move to the next phase. In other words, the phase “gate”
is now open to enter and pass through.

103
Three warning signs that your project is doomed
It is likely that you will end up on a failing project at some
point in your career. Of course, that’s something we’d all
like to avoid. Failures are demotivating at best and career-
threatening at worst. If you could take action to save a
project, you probably would. Unfortunately, unless you
are the project manager, you may have little opportunity
to affect the success or failure of the project. You can,
however, learn to spot impending problems so that you
have a chance to land on your feet.
This article looks at three business-related warning signs
to help you recognize that a project is headed for trouble.
While not exactly scientific, these signs can provide some
early warning. And although you probably won’t be able
to save the project, you may be able to save yourself.
Included at the end of the article are some recommended
actions you can take if you find yourself on a failing project.
The stats
The statistics for successful IT projects are not encouraging.
According to a report by The Standish Group (a business
research organization), nearly one-third of all Information
Systems (IS) projects are cancelled before completion. In
addition, one-half of all projects overrun their budgets.
Surprisingly, the reasons for failure are rarely technology
related. In the software management book Peopleware:
Productive Projects and Teams, coauthor Tom Demarco
notes that the overwhelming majority of projects fail for
reasons other than technology. But if it isn’t the technology,
what’s causing these projects to fail? The reasons are peo-
ple- and process-related. Ironically, the average developer is
more comfortable dealing with technology-related problems
and less so with people- and process-related issues.
Problem # 1: Lack of a
compelling business case
Surprisingly enough, some projects get underway without
a compelling business case to support them. A business
104
case is important because it provides the foundation for
the project. It should offer a cost-benefit analysis and will
often consider business risks and the impact of external
events on the project. Organizations use business cases
to prioritize their limited resources for those opportunities
that will provide the greatest return.
So how does a project get started without a business
case? This can happen because the business owner for
the project “just wants it” and is powerful enough to make
it happen. Another possibility is that IT organizations think
the business unit needs it, so they build it.
In the last two years, many Web-related projects were
started without business cases because organizations
believed that they had to do the project to remain com-
petitive. There was a sense of urgency, of getting out in
front of the wave. The dot-com crash has meant a return
to business basics, including business cases.
What you should do: Find out if your current project is
supported by a business case. Get a copy of the business
case and read it. What are the business drivers for the
project? Is the business case logical and understandable?
What assumptions underlie the business case? What are
the risks? What external events could affect the business
case? If you do not find an understandable, compelling
business case for your project, find out why no business
case has been developed.
Problem #2: No agreed-upon
requirements or system
specification
Lack of requirements can indeed be a dangerous thing.
In the Standish Group report, the three most-common
factors in challenged projects were requirements related.
Requirements suggest the size and shape of the system
being built. They define what the system should and
shouldn’t do.
Requirements management is the process of defining,
documenting, tracking, and managing requirements
throughout the project life cycle. This helps to ensure that
the final solution meets the needs of the users.
What you should do: Keep a close eye on your require-
ments management process. If no one seems to be
managing a list of requirements for the system, or if the
requirements seem to be constantly changing, then you
may be headed for trouble.
Problem #3: Lack of a current,
published project plan
Amazingly enough, some projects are still being run with-
out a project plan. This is like building a house without a
blueprint. Every project is a unique undertaking and each
should have a project plan. Period. Plans are essential
for communications with all stakeholders, for providing
an indication of progress, and for determining the work
remaining to be completed.
One argument against having plans is that people don’t
need to be told; they somehow “know what to do.” This
approach may work on a project team of one but is unten-
able with anything larger. People do need to be directed.
They want to know the priorities. They don’t want to have
to guess at what is most important.
Having a plan is only part of the battle: The plan should
also be kept current. Have you ever been on a project
where the kickoff was held in a room wallpapered with
fancy Gantt or PERT charts, only to find that those same
charts remain on the walls for months or years without
any change? That is not a current plan. To be current, the
plan must reflect actual work completed and offer a realis-
tic forecast of what remains to be done. Plan updates
should be done no more frequently than once a week and
no less often than every two weeks. The plan should ac-
curately reflect the time and cost to complete the project.
Only then can the plan be considered current.
105
Just as frightening as having an out-of-date plan is one
that changes each week. I have monitored projects where
each week that passed caused the end date to extend out
by one week. The plan was up to date each week, but the
project was still out of control.
What you should do: If there is not a published plan, ask
for one. If you are told that you can’t see the plan because
the information is considered confidential, take that as a
serious warning sign. Unless you are working on devel-
oping the next generation of the nuclear bomb, there is
probably no good reason for a confidential plan. Keeping
the information secret is usually an indication that the
management knows there is a problem with the project
and they are trying to keep it under wraps.
Make sure the plan is updated at reasonable intervals. It
shouldn’t be a moving target, but it must be up to date. If
you can’t get a current, published plan, start to worry.
My project is failing—now what?
What if you find yourself on a project with one or more of
these warning signs of failure? Your response will depend
on your personal situation. If you feel you can help the
situation by taking action, by all means you should do
that. Talk to the project manager, the client, or the other
members of your team. Discuss your concern in a factual,
nonthreatening way. Try to be as positive-minded as pos-
sible. See if you can affect the needed change.
If that fails and you find you have no control over the
situation, try to find a way off the project. You may be able
to find a better project in the same organization or you
may have to leave the organization. In either case, leave
the project on a positive note. This is not the time to tell
anyone how little he or she knows about running projects.
If you are truly stuck on the project or if you are waiting
to leave it, try changing your perspective. Treat it as a
learning experience. What can you gain from the situa-
tion? What specific actions would you take to change the
situation if you were empowered? How can you avoid
being on a project like this in the future? Take from the
situation everything you can that will be helpful to you on
future projects.

Just the beginning

These three issues all have to do with business and plan-
ning, but of course, there are many more factors that can
signal a project’s demise. Next time, we will look at four
factors that involve users and stakeholders and see how
they can be a further warning of bad things to come for
your project.

106
Use the tradeoff matrix to foster collaboration
in agile projects
While making prudent project compromises and tradeoffs
is a critical success factor in any project, in agile projects,
there are certain factors that make it more challenging and
more crucial.
Linear projects
In a typical linear or waterfall project, the requirements
definition process is a distinct and front-loaded exercise,
and much of the negotiation over features to be included
is done up front. In fact, this early scope definition pro-
cess, with all feature determinations and “horse-trading”
done before any design or development begins, is the
defining feature of a traditional project approach. Anyone
who has ever worked on a traditional project knows that
new features and ideas will arise during the design and
development phase, no matter how frosty the “frozen”
specifications are; however, in a disciplined methodology,
these modifications will be managed by a change control
process that will require a detailed impact analysis and
the submission of all change ideas to a Control Board for
further evaluation.
These controls solve the problem of scope creep (which
has always plagued IT projects), but the controls create
unintended consequences. The process of capturing the
client’s changing requirements and developing and docu-
menting an impact analysis and then shepherding that
through a Change Control Board is time-consuming and
resource intensive. Also, the process is so onerous that
people are discouraged from making a change request,
which, in the days of frozen specs and linear projects, was
considered a positive.
Agile development
The key insight of agile development is that change, while
inconvenient for the development team, is frequently benefi-
cial. In fact, openness to beneficial change is the catalyst for
107
projects that actually deliver what the customer wants and
needs in a dynamic and turbulent business environment.
One of the key tenets of agile development is transpar-
ency. We collaborate closely with the client and other
stakeholders throughout the project so that they can see
the design decisions we’re making firsthand; they can
also work side-by-side with us as we grapple with the
tradeoffs and the compromises that are a key part of any
product development project.
In order to stay true to the agile concept of openness and
visibility, I recommend using the tradeoff matrix as an aid
to facilitation and discussion when modifying the feature
set we’re committed to deliver.
Using the tradeoff matrix
The tradeoff matrix is not a new idea, and it’s not exclu-
sive to agile development. I first encountered it when
training in the Microsoft Solutions Framework (MSF), a
software development life cycle promoted by Microsoft for
its development partners and internal teams. Although the
MSF was originally offered by Microsoft to partners and
developers as a program of guidance for development
disciplines, it has evolved into an agile-friendly methodol-
ogy that endorses many of the collaborative, iterative
concepts that are common to agile methods.
Every PM is familiar with the triple constraint; that is, the
idea that projects are always constrained by schedule
(or time), by features (or scope), and by resources (which
include money and talent). When any of these elements
change, it requires a tradeoff in one of the other compo-
nents. For example, adding scope typically requires that
the schedule be extended or that resources be added,
while decreasing time or resources usually means that the
feature set must be reduced. I say typically and usually
because every PM has experienced the client or man-
ager who insists on changing elements of the constraint useful at the feature level, when clients are attempting to
without making corresponding adjustments in the other add features, to remind sponsors of the agreements and
constraints. This rejection of reality by project sponsors is a priorities set at the beginning.
driving concept behind agile development. One reason we
The tradeoff matrix is often used as an internal tool for
collaborate with the client or sponsor, bringing them com-
conversation and agreement by the development team.
pletely into the process, is because only they know what
In the agile world, however, it becomes a much more
they’re visualizing for the product. Agile practitioners insist
inclusive conversation, in which sponsors, managers, and
on the sort of transparency that makes it clear to all partici-
users also participate in the conversation and have a vote
pants that wishes, threats, or miracles cannot change the
in the outcome. In agile environments, tradeoff conversa-
fact that additional scope takes time and resources.
tions are run as facilitated work sessions, and the agile
The tradeoff triangle (or the triple constraint) is a useful PM leads the collaborative team through the process of
tool for educating clients and sponsors regarding the un- filling in the blanks to the following sentence:
breakable connection between time, scope, and cost. The
Given fixed _________, we will choose a ______ and
use of the tradeoff matrix (depicted on TechNet) takes this
adjust ________ as necessary.
conversation a step further. It requires the working team to
recognize the reality of the project at hand by categorizing Whether the team is setting priorities for an entire project,
each constraint as either fixed, chosen, or adjustable. an iteration, or a specific feature, the questions are the
same: For the particular project element under review,
Fixed constraints (e.g., the drop-dead project
where must we conform to our previous plan, and where
delivery date) can’t change.
is there room for compromise? In an iterative, time-boxed
Chosen constraints are based on priority choices
development project, such as Scrum, where, for example,
made by the team and its sponsors. For ex-
the typical iteration is constrained to 30 days, we’d start
ample, the decision that, for a particular project
with the premise that:
or iteration, meeting schedule is more important
than including all features, and so some features Given a fixed schedule, we will choose a level of

could be compromised out or “de-scoped” if resources and adjust the features set as necessary.

necessary to meet the schedule.

Depending on the project and the determinations made
Adjustable constraints are subject to negotiation by the team, the resources or budget may be the fixed el-
and compromise. ements, requiring compromise in time or features. The key

The tradeoff matrix can be used at the project level to point is that these decisions are made by the entire team

document an agreement between the development team in full view of all so that issues and disagreements can be

and its sponsors that the entire project will be focused worked through. Also, these decisions are made in rec-

on meeting schedule, for example, and that features and ognition of the reality that, while agile projects are open

resources can be negotiated and changed. It can also be to change, change is not cost-free, and any modifications

used at the iteration level to ensure that all team play- in features, schedule, or resources requires adjustment to

ers have a consistent understanding of the priorities and the other elements of the tradeoff triangle.

possible adjustments to this particular iteration (priorities

can change from iteration to iteration, as teams reach the
boundaries of schedule or budget, for example). It’s also

108
10 things you should do near the end
of a project
Depending on the size of your organization, you may treat your customer think? Schedule time with customers to
project management as a casual practice or you may review all the deliverables and ensure they have been
have an involved PMO. In either case, you probably go met. In some cases, there may be a few outstanding is-
through the typical inception, elaboration, and construc- sues still unresolved when you get to your scheduled end
tion phases of a project. But when it comes to the end date. Early on in your project, you should have made an
of a project, many project managers come up just short agreement that determines how this will affect your end
of the finish line. Failure to handle the final steps can date if this situation occurs.
add confusion to an initiative and may lead to customer
dissatisfaction, unhappy staff, and a project dragging on
4: Get project signoff
After you’ve agreed that all the deliverables have been
longer than necessary.
met, request a formal signoff on the project documenta-
Here are a few things you should be thinking about when tion. Doing so helps ensure that everybody is in agree-
you get to the end of your next project. Some of these ment on the state of the project. Since this signoff usually
items are purely administrative, but many of them will help signals the formal end of the project, be careful not to
get you one step closer to ensuring that your project is make your customers feel pressured into signing. If they
successful. do this without understanding what it means, you will
likely end up with an unsatisfied customer if an issue
1: Finalize testing
arises at a later date.
Testing can be a drain on people, and many of us don’t
like to do it — especially when it takes a few rounds. I
5: Release the team
have seen complex projects that were four to six months
Now that the project is done, where is your team going?
long have a day or two scheduled for testing. Not sched-
Depending on the organization, they may be sent back to
uling an adequate amount of testing usually ends up
a development pool or into the business. Or maybe they
with problems occurring during the first few weeks of an
need to go drum up some work for themselves within the
implementation. Don’t take a shortcut here and minimize
company. No matter what it is, make sure you spend time
the importance of testing; otherwise, you’ll take on the
with them and set a clear end date for when you no longer
additional risk of having a painful rollout.
need their services. Also don’t forget that you probably
need to complete any performance review documents
2: Finalize training
that need to be added to their file.
Users? Who cares about users? Well, many projects are
done for their benefit, so make sure you have all your test-
6: Analyze actual vs. planned
ing materials completed and delivered. Failure to do so
Resources. Did you really get away with only one devel-
will most likely manifest itself in the form of angry phone
oper/tester for 10 weeks or did you need to scramble and
calls from irate users in the middle of the night.
get more people? What about the amount of time you
scheduled for your business partners? Understanding
3: Validate deliverables
how well you hit these targets will help you better allocate
You’ve checked all your boxes and cleaned out your
resources for your next project and set more realistic
inbox, and you really think you’re done. But what does
expectations when it comes to a project’s duration.

109
Budget. How much was the project going to cost? Did
you come in on budget, under budget, over budget?
Sitting down to understand the answers to these basic
questions should give you some insight into a critical area
of any project.
and will give you some great direction in deciding which
personal growth opportunities you should focus on.
This list won’t be the same for everybody and will depend
on your organization and how it implements projects. But
if you can do them, it will always make the transition to

7: Archive documentation the next project smoother.

During any project, we seem to create huge amounts of

documentation. It can range from scope documents and
project plans to contracts and meeting minutes. Whatever
it is, when you are done you should have someplace to
keep it based on the retention policy of your company.
You’ll be glad you did when your phone rings two years
from now and somebody asks you to explain the rationale
behind a choice you made during the course of the project.

8: Ensure contract closure

It’s not unsual for a project to have its own budget. You
also may have contracts for hardware, software, or pro-
fessional services. When you’re done, make sure that you
verify that all the terms of your contracts have been met,
request final invoices from vendors and submit them to
AP, and close out any associated financial accounts,
if necessary.

9: Conduct a postmortem meeting

What typs of risks did you identify and mitigate? What
went really well that you want to ensure you do again next
time? Have a meeting with all the project stakeholders
and relevant participants to provide them with a forum to
express any lessons learned.

10: Perform a self assessment

So it’s finally over. After all the hard work has been com-
pleted, you’ve made sure that all the i’s have been dotted
and all the t’s crossed. Now what do you do? It’s impor-
tant to get some feedback on your performance from
the people you interacted with during the project. If you
have the opportunity to send out a 360-degree feedback
survey to as many individuals as possible, I would recom-
mend it. It will help you assess how you’re progressing

110
Agile project management tips 3
Four variants of agile development methods
The developers who gathered to develop the Agile to teams larger than 10 or so, and it’s not well suited to
Manifesto were not just theorists; they were dedicated virtual or dispersed teams.
practitioners, who went on to create development meth-
XP is presented as a series of principles that agile devel-
ods based on the agile principles.
opers should follow. These elements include the following:
Ken Schwaber and Jeff Sutherland were the originators
The planning game: A recurrent workshop
of the Scrum methods we’ve reviewed. Kent Beck, Ward
in which developers and customers interact
Cunningham, and Ron Jefferies, also signers of the Agile
in order to create and refine the “stories” that
Manifesto, are codevelopers of Extreme Programming,
describe their project.
which many associate with the idea of agile software
development. Alistair Cockburn, another signer of the Small releases with high-value elements:
Agile Manifesto, is the architect of the Crystal methods “Every release should be as small as possible,
and is an author of influential works on Use Cases. containing the most valuable business require-
Manifesto signer Jim Highsmith has been the chronicler ments.” - Kent Beck
of the agile movement and has done the most to migrate
Metaphor: The overall idea of the project; the
agile concepts from the software to the project
broad goal told as a narrative or story to keep
management community.
the technical jargon to a minimum and build a
In previous project management columns, we discussed collaborative vision between developers and
some principles of agile development and looked at the customers.
Scrum agile methodology in detail. Now we’ll explore
Simplicity: The ideal of simplicity is central to XP.
each of these variants of agile methods and discuss
The delivered product itself should be simple,
criteria for selecting one approach or another based on
delivering the needed features in the simplest
the project at hand.
manner without trying to speculate about the

Extreme Programming (XP) bells and whistles that might be useful some-

XP has received the lion’s share of interest among agile time in the future. The use of methodology and

methods. XP drew attention because it converged with technique should be simple too; XP developers

many of the practices that developers were discovering in avoid documentation, other than stories and test

real project work and because its initial successes, includ- cases, unless there’s a convincing demonstration

ing the well-known Chrysler Comprehensive Compensa- of their value to the customer. XP practitioners

tion project, coincided with the Internet movement, with strive for elegance and simplicity in their actual

its need for an approach geared to speed-to-value and coding practices, which leads us to refactoring.

exploratory, innovative projects.

Refactoring: Refactoring is the optimization of

XP is unique among the agile methods surveyed here the internal code and architecture of software,

because it is focused on software development, and it is and it’s a key element of XP. It’s also a response

not presented as a project methodology. XP doesn’t scale to one of the hazards of iterative design, the
danger that the separate iterations will be poorly

111
 integrated and internally incompatible. Refac- development communities the chance to consider these
toring is a disciplined approach to rebuilding ideas and to explore their applicability to their work.
system internals to ensure simplicity, elegance,
and compatibility.
Dynamic System Development
Model (DSDM)
Pair programming: Pair programming takes
Developed in 1994, DSDM is the oldest of the recognized
the concept of software inspections and walk-
agile frameworks. DSDM was developed as a structured
throughs to the next level. Rather than periodic
approach to Rapid Application Development, a popular
reviews, the key insight of pair programming is
methodology of the early 1990s. It incorporated many
that two skilled practitioners can review and
of the fundamental concepts of iteration, incremental
optimize each other’s code and each other’s
delivery, and customer collaboration that typify the agile
coding practices, as they work toward the
methods that have become popular since the Agile Mani-
customer’s goal.
festo was published.

Testing: The vital difference between XP testing

The DSDM Consortium defines DSDM as “a project deliv-
practices and traditional practices is that XP in-
ery framework that aids the development and delivery of
sists that test cases for all features be developed
business solutions to tight timescales and fixed budgets.”
up front, with the stories.
It is focused on the concept that customers can’t foresee

Continuous builds: Going beyond the “daily all the detailed workings of their system or product in

build” that’s a common practice in many com- advance. The DSDM Manual informs us that “the current

mercial software companies, XP practitioners step need be completed only enough to move to the next

prefer the continuous build, ensuring compatibil- step,” a nice distillation of the incremental, iterative ap-

ity and functionality continuously as the product proach common to agile methods.

is created.
DSDM is unique among methodologies in that it follows

Sustainable development: A reaction to the a Consortium model, with members paying an annual fee

70-hour week “death march” project that many (of about $2,000 a year) to remain members and retain

developers have experienced, the 40-hour-week access to the licensed use of the methodology. As such,

standard that XP espouses is consistent with the it has the most developed training, support, templates,

agile philosophy that creative developers do their tools, and accreditation services of the agile methods

best work when they’re committed, energized, (although Scrum, with its Scrum Master series of certi-

clear, and focused. fications, is close). The consortium structure has also,
however, been a factor in DSDM’s slow adoption.
Available customer: XP calls for the customer to
be completely integrated with the development DSDM is an interlocking set of processes, each of which

team; available to review features, builds, and is iterative and incremental. While the model is complex

tests; and to review, assess, and optimize the and daunting, it is basically a three-step iterative model,

product as it evolves. consisting of Modeling, Design-Build, and Implementation

phases. Once mastered, it has been proven to have some
XP’s broad exposure, and the debate it has engendered, significant benefits in speed, team productivity, customer
has given the project management and software satisfaction, and product fitness for its visualized use.

112
More detail on the individual processes is available at the
DSDM Consortium’s Web site.
DSDM contrasts with some agile methods by its strict en-
forcement of “timeboxes,” with preset start and end dates
and with a preselected team. Functionality may change,
but the delivery date does not. This strict time manage-
ment is a reaction to the ubiquitous problem of missed
delivery dates for new software and products.
DSDM employs a strict method for prioritizing require-
ments, which categorizes features as “must have, should
have, could have, want to have (but won’t this time).”
Since functionality can change but time and team compo-
sition don’t, DSDM’s emphasis on feature priorities helps
teams focus on the features that deliver business value
and relentlessly drive for efficiency and simplicity.
DSDM is a noteworthy example of a methodology that
was developed prior to the release of the Agile Manifesto
but has evolved significantly to be consistent with the
ideas generated by the agile community.
Crystal Methods
Alistair Cockburn, the developer of the collection of
methodologies known as Crystal Methods, says that he
developed Crystal Methods to “get rid of this aberration
called software engineering.” Engineering, he says, gives
us questions like “Is our model accurate?” instead of the
more interesting questions such as “Is our product
meeting the customer’s needs?” and “Do we have our
goals aligned as a team?” In line with Cockburn’s
emphasis on these questions, Crystal Methods is
primarily focused on communication, with special focus
on interaction, community, people, and skills.
As noted, Crystal Methods is a collection of methodolo-
gies based on two fundamental assumptions: (1) teams
can streamline their process as they work and become
a more integrated, optimized team and (2) projects are
unique and dynamic and require methods that are specifi-
cally designed for each effort. Another theme that has
113
run through Cockburn’s work from his first articles to his
current Crystal Methods development work is the concept
of product development as a game, a cooperative,
interactive activity that should be designed in a way that
stimulates the creativity of all participants.
Crystal Methods recommend a specific methodology for
each project based on three critical factors: communica-
tion density (more people means more communication
channels and increased complexity), system criticality,
and project prioritization. The smaller the team, the more
likely it can just retire into a conference room and build
the product, without a lot of status reporting, knowledge
transfer, or written documentation. As the team size
increases, the number of communication “artifacts” like
written notes, necessarily increases, and Crystal Methods
enable that increase by presenting different methodolo-
gies and processes for different projects.
Lean Development (LD)
In 1989, Professor James Womack and consultant Daniel
Jones published Lean Thinking, a survey of the lean man-
ufacturing techniques that helped create the “Japanese
miracle” of the late 1980s and early 1990s. They chroni-
cled the ideas of lean manufacturing, with their focus on
eliminating waste, creating a smooth “flow” of work on
the factory floor, and expecting workers to contribute high
skill levels and an ownership mentality. These concepts
helped Toyota, the exemplar of these techniques, vault
over the traditional giants of the automotive industry.
Lean manufacturing theories were highly influential in the
creation of LD. Bob Charette, while not a signatory of the
Agile Manifesto, has developed a methodology that has
many commonalities with those mentioned so far. Similar,
though distinct, ideas have also been put forward by Mary
Poppendieck and Tom Poppendieck in their book Lean
Software Development (we focus on Charette’s
version here).
LD emphasizes four key success factors that clearly il-
lustrate its compatibility with other agile methods:
 Create visible customer value rapidly,

Build change-tolerant software,

Create only necessary functionality and no more,

Adopt aggressiveness, stubbornness, and belief

in meeting stretch goals.

Like Scrum, LD is more of a project management en-

vironment than simply a software development one; it
consists of three distinct phases: start-up, steady-state,
and transition / renewal. Rather than the daily “Scrum,” it
recommends a time-boxed “whirlpool” that, like all agile
methods, includes the analysis, design, test, and build
activities in each iteration.

Lean development is important not just for its confor-

mance to the ideals of agile development but because the
underlying philosophies of lean manufacturing have been
accepted by business leaders worldwide, and so come
with existing acceptance. This makes introduction of agile
methods in a lean framework more easily accepted and
presents a strategic framework that executives are likely
to accept with less resistance.

Summary
There are other agile variants we haven’t explored here,
including Feature Driven Development and Jim Highsmith’s
Adaptive Software Development. Some agile variants, like
Scrum, are primarily focused on the project management
element of product development, while others, like XP, are
software centric. The agile ideas outlined here have not
just created debate and discussion but have led to the
crafting of a variety of disciplined, complete methodolo-
gies that bring the theories into real-world practice.

114
Five agile project management migration tips
I’ve written previously about the ideas and philosophies
that form the foundation of agile project management.
The history of project management, especially as it
applies to IT, has resembled a pendulum, swinging from
the lax controls and do-it-yourself ethic of the early
mainframe “glass room” to the rigorous methodological
controls and formal software development life cycles
(SDLCs) of Project Management Body of Knowledge
(PMBOK), Capability Maturity Model (CMM)-enforced
practices. Many IT shops have fought painful ideological
and cultural battles to make the transition to disciplined
project management; in my career, I’ve seen the Project
Management Institute (PMI) certification evolve from an
obscure and unknown credential to a virtual requirement
for employment in many organizations. We’ve also seen
CMM certifications become critical differentiating factors,
especially for offshore IT service providers, who have
used CMM Level-5 certification as an “assurance factor”
to help Global 500 firms feel comfortable outsourcing to
far-off partners.
I’ve developed project management offices (PMOs) and
project management methodologies for large IT firms and
service shops, and I’m a strong advocate of adding these
disciplines to the corporate toolkit to improve delivery
consistency and process excellence. Now that I’m working
with firms to train them in agile methods and to help them
migrate to agile, however, I’m finding that these same disci-
plines that brought such strong benefits in project success
rates can also be an impediment to agile adoption. Many
firms have committed so completely to PMBOK process
flows and CMM best practices that many of the core
concepts of agile development, such as “barely sufficient”
documentation and change-friendliness, seem like heresy.
In fact, I’ve had people in my Agile Project Management
classes tell me that their perception of agile is that the key
message is “everything you know about project manage-
ment is wrong.” While this may in fact be the message of
115
some purists in the agile community, I’m much more of
a pragmatist, and my counsel to firms migrating to agile
methods is that, not only can agile and traditional project
methods co-exist, but in fact, in most organizations and
for most projects, a hybrid approach is key to success.
Bridge to agile PM
In her outstanding book Software Project Manager’s
Bridge to Agility, Michele Sliger walks readers through
the PMBOK and relates agile concepts to the well-known
Project Management Institute (PMI) knowledge areas
and process areas. Sliger’s key message is that both the
agile and traditional project management camps have
misconceptions about the ideas and capabilities of the
other side. Some PMI-focused PMs and organizations
believe that PMI and the PMBOK don’t support agile
methods, and that migration to agile automatically means
abandoning PMI ideals. Conversely, some agile propo-
nents believe that PMPs are so committed to “predictive”
project methods that they can’t become agile. By relating
the key practices of traditional PMOs, such as time, cost,
and risk management, to agile approaches that address
the same requirements in a slightly different way, Sliger
demonstrates that the foundation disciplines of project
management remain intact as your enterprise becomes
agile, and that only some tactics and approaches change.
For any enterprise considering migration from PMBOK-
style project methods to more agile approaches, Sliger’s
book is a must read.
Agile lessons learned
From my experience in the trenches, some of my key
lessons learned for PMBOK, CMM-style shops are the
following points:
Sell: Evangelizing the benefits and features of
agile methods and ensuring that the sponsor-
ship exists to make this often wrenching and
difficult transition are prerequisites. Each of
your audiences will need a different sales pitch;
managers need to understand that agile teams
can plan, that we do estimate, and that we can
create a long-term strategic roadmap that gives
them the information they need to budget and
set expectations (ideas that conflict with agile
myths). Development teams need to internalize
the leaps in self-direction, creativity, and maturity
that working in an agile environment can enable.
Many agile teams observe that the expectation
of self-direction encourages them to take re-
sponsibility and ownership of their commitments,
and to develop mature skills like facilitation and
negotiation. And PMO managers need to under-
stand that their hard-won battles for discipline
and consistency were not in vain.
Train: A robust training program for all audiences
is the next key element of a successful transition
to agile. The language is different, the develop-
ment life-cycle is different, and the foundational
philosophies of iterative development, constant
customer involvement, minimal project manage-
ment “ritual,” and change-friendliness must be
understood and embraced for the organization to
be united and prepared for the evolution ahead.
Pilot: Many organizations transitioning to agile
select specific projects, typically suitable for an
agile approach due to their innovative nature and
their need to quickly respond to changes in the
technical, business, or competitive landscape,
and run them as “skunkworks” outside the
standard PMO line of command. This allows
development teams to quickly sidestep some of
the process overhead that often accompanies
SDLC-compliant programs, without requiring the
organization to change its sanctioned approach
without proof that agile works, and is suitable
culturally for the company. To give a negative
116
example, I recently worked with a team that is
experimenting with agile methods, but is still also
required to comply with strict PMO documenta-
tion and process requirements. This “double
duty” is not a fair test of agile methods and, in
fact, dooms agile to fail as it requires even more
overhead, such as both burn-down charts and
Gantt charts, and both story-driven and task-
driven project plans.
Reflect: Once the team has a few agile projects
under its belt, honestly reflect on what was best
and worst about these efforts. These retrospec-
tives should focus on the process of delivery and
the actual deliverables, and should concentrate
on the idea of balance and adaptiveness. Which
elements of the existing, PMBOK-compliant
methods must stay, because they add real value
and also provide the predictability and comfort
level management needs? Which agile methods
have demonstrated that they can enhance the
creativity and self-motivation of the team, and
boost the collaborative spirit between the devel-
opment team and the business sponsors?
Adapt: Adaptiveness is, in my view, the key to
successful agile implementations. In fact, Jim
Highsmith, a signatory of the Agile Manifesto
and the author of the influential book Agile
Project Management, uses the language of
“adaptive development” as his core explanatory
term for these methods. The agile approach
that any enterprise adopts must be adapted to
fit the culture, the risk profile, the history, and
the preference of all the affected audiences.
By experimenting with agile methods in some
key “skunkworks” projects, honestly assessing
their successes and challenges, and looking for
the right mix and balance for your organization,
your chances of a successful migration increase
substantially.
Just as many firms took a long time to evolve from the
“glass house” of mainframe development to the disci-
plined approaches of SMM and PMI, firms should expect
migration to agile to be a process, not an event. Small
steps are more easily digested by all audiences, and,
although they may not bring the quantum leap in inno-
vativeness and speed that a rapid agile adoption might,
they make up for that by being acceptable and comfort-
able, and by preparing the way for success iteratively and
incrementally, and iterative and incremental improvement
is what agile methods are all about.2

117
Adaptive Project Framework:
A new level of agile development
In the Agile Project
Management classes
I teach, one of the
first things I do is
write two words on
the board and then
tell my students that
these words will be
key to understand-
ing everything we’re
about to talk about
in regard to agile
concepts.
The first word is adaptive. I emphasize with my students that
adapting the project approach to the specific effort at hand
is a fundamental concept that underlies all agile methods.
The second word is hybrid. I assure my students that
while some agile proponents are almost religious in their
insistence that Project Management Institute (PMI)-style,
traditional methodologies have no place in an agile
environment, my philosophy is that almost every proj-
ect, every client, and every organization will require us
to incorporate some traditional methods into our agile
approach. It’s my experience that very few organizations
desire, or are prepared for, a complete migration from tra-
ditional tools, such as project plans and Gantt charts, to a
total agile approach founded around the idea that if you’re
running a traditional product development lifecycle and
applying PMI standards, everything you know is wrong.
Adaptive Project Framework
Robert Wysocki, author of one of the foundation texts
on project management, Effective Project Management:
Traditional, Agile, Extreme, seems to agree; his new book,
Adaptive Project Framework, focuses on the proposition
118
that since most current IT projects evolve as they go and
begin with uncertain requirements, traditional project
methods are not applicable.
Wysocki argues that the vast majority of today’s projects
include uncertainty in project characteristics that extend
far beyond the requirements. He cites typical project ele-
ments familiar to traditional project managers, such as:
Risk
Cost
Duration
Complexity
as well as project variables such as:
Market stability
Business value
Client involvement
Goal and solution clarity
to make the point that since these components vary
widely from project to project and from client to client,
PMs must be prepared to adapt the project approach
taken to ensure a proper fit between effort and approach.
Wysocki uses an analogy to make his point that I think
clarifies his ideas nicely. He differentiates between the
cook, whose skill lies in following a recipe accurately and
consistently, with a chef, who has the experience and
skills to create new recipes for each dish and to
improvise within existing recipes based on the
circumstances at hand.
Traditional PMs who work within strict Project Man-
agement Office guidelines are expected to adhere to
unchanging development lifecycles; these PMs can
deliver consistent results if the goal is well-defined and
the solution is understood. Adaptive PMs, according to
Wysocki, thrive in environments where the project goals
are not yet completely specified and may evolve as the
project progresses and where the solution is speculative.
In fact, he offers a “magic quadrant” that illustrates his
point by pointing to Goals and Solutions as key variables,
and Known or Unknown as the defining attributes. When
both goal and solution are known, such as a repetitive
effort to build a data center by copying exactly an existing
facility, traditional methods are probably the best fit. It is
in those situations where both the goal and the solution
are unknown and where the expectation is that through
continuous refinement and incremental delivery, these
variables will be refined and discovered, that an adaptive
approach is most suitable.
Many of the attributes of Wysocki’s Adaptive Framework
are familiar to us from our previous reviews of agile
methods:
they thrive on change;
they learn by iterative delivery and discovery; and
they are client driven and have an inherent
expectation of deep client involvement.
Wysocki addresses this last point of client involvement in-
depth. He notes that for the first time the 2007 edition of
The Standish Group’s famous Chaos Report cites “lack of
meaningful client involvement” as the number one reason
for project failure. This leads him to assert that the best
project management structure, for those high-uncertainty
projects that warrant an adaptive project approach, is one
in which the client assigns a co-PM for the length of the
project, with decision authority for the client side of the
engagement. “The co-project manager model is unique
to APF,” Wysocki notes, “and is a critical success factor
for such projects. The most important characteristic is
that both parties are equally vested and responsible
for the project.”
Another unique characteristic of the Adaptive Framework
is its approach to requirements definition. Traditional PMs
119
are accustomed to a template-driven approach, such as
the Robertson Volere Requirements Specification tem-
plate, in which the development team questions the client
and stakeholders, walking through a voluminous template
and often asking questions that, due to uncertainty or lim-
ited technical background, the client is unable to answer.
Alternatively, many agile approaches offer a story-driven
approach to requirements definition. Adaptive Projects
take a different tack; Wysocki offers a requirements
process based on a Requirements Breakdown Structure,
a hierarchical definition that begins with a top-level,
strategic project goal and then progressively decomposes
that goal into a four-level structure:
Requirements
Functions
Sub-functions
Features
He makes a nice distinction between the Requirements
Breakdown Structure and the traditional Work Breakdown
Structure: “The RBS answers the question ‘What are we
going to deliver?’ The WBS…answers the question ‘How
are we going to deliver it?’”
Conclusion
When a reviewer calls a book dense, it’s often not meant
as a compliment, but instead intended to imply that the
book is difficult, inaccessible, and obtuse. Wysocki’s book
is dense, but in the best sense of the word; rather than
offering vague concepts and high-minded advice,
he presents a clear set of values and fundamental
approaches and then presents a detailed execution
model that walks practitioners through the process of
implementing his ideas. His book is not meant for
skimming; every page rewards patient readers with
valuable insights and stepwise methods for applying his
framework.
Wysocki makes some strong claims for his Adaptive Proj-
ect Framework. According to him, projects that follow the
Adaptive Framework deliver projects faster, cheaper, with
higher quality and better business value. He goes so far
as to state that his approach delivers successful projects
every single time without fail. While I’m not prepared to
endorse these claims, it’s clear to me that Wysocki’s
Adaptive Project Framework is a valuable addition to the
PM literature and takes the ideas of agile development to
another level of reality and pragmatism.

120
Agile reporting methods for project managers
Before we explore specific agile reporting methods, it’s
important to return to fundamental principles and refresh
our motivations for project status reporting. No project
manager (PM), agile or traditional, denies that stakehold-
ers deserve visibility into the project for which they are
paying and on which they are relying for added business
value. Any disagreement is one of degree and focus.
In traditional project management, we often spend a sig-
nificant amount of our development time either trying to
predict our development path or trying to track our path
against these predictions. We frequently find ourselves
pitted against our own predictions as we report to our
customers (”you said you’d be 56% complete, but you’re
only 42% complete… what went wrong?”). One of the
unspoken misfortunes of traditional project methods is
that the PM and the team typically start out behind and
in trouble and get progressively deeper and deeper into
“task debt,” destroying the team morale and diverting the
PM from productive leadership activities to justification
and detail obsession.
Many organizations have invested significant energy into
the creation of Project Management Offices (PMOs) and
have defined strict guidelines for the reporting processes
required to keep managers and other stakeholders
informed. Past project failures, rather than pointing to the
need for a new, innovative approach to project manage-
ment, have instead led some PMO teams to apply tighter
discipline to project reporting and change control. This
often turns the project plan and the Gantt chart (rather
than actual delivered product features) into the central
indicators of project progress. Project failure is interpreted
to prove that the process wasn’t rigorous enough. This
forces PMs to include more granular task detail in their
plans and Gantt charts and risks turning them into project
bureaucrats rather than team leaders.
121
Scrum Agile reporting techniques
The agile concept of “barely sufficient,” which we apply
to project documentation, also applies to reporting; we
obviously need to keep the team and customer informed
on our progress, but it’s key to remember that we’re here
to build business value, not to tick tasks off a list.
The reporting techniques we apply must concentrate
on value delivered, in the form of features developed or
requirements satisfied, and avoid getting us dragged
down into the “task check-off” mode that traditional
methods often enforce. For organizations accustomed to
the project plan and Gantt chart, this becomes a cultural
transition challenge as well as a simple project visibility is-
sue; for PMOs and managers comfortable with traditional
tracking and reporting methods, new techniques can be
disorienting and intimidating.
Using Scrum as an example, the reporting expectations
are clearly defined; different agile methods have different
standards. In Scrum, we typically create four reports at
the end of each iteration:
the Product Backlog, which lists all the features
that make up the entire product
the Sprint Backlog, which include the features
we’ve committed to deliver in the next iteration
the Changes report, which details the differences
between the Product Backlog and the Sprint
Backlog
the Burndown report or chart, which illustrates
(usually in the form of a trend graph) the work
we’ve actually “burned through,” giving us a real-
world view of the team’s progress
Product Backlog
The Product Backlog is the master requirements
repository for the entire effort. All the stories, or features,
you’ve uncovered so far in your conversations with the
product owner and other stakeholders are listed and
prioritized here.
Unlike a comprehensive Business Requirements
Document, as seen in traditional project management,
features requested are simply listed in a one-line de-
scription, and any elaboration or further definition, as
discovered during conversations with customers, are kept
separately from the Backlog and are typically “owned”
by the developer who has taken responsibility for each
feature. Backlog formats vary widely based on team
preference but typically record at least the feature de-
scription, a relative size estimate, and some indication of
priority. For more detail about Backlogs, read the Scrum
Alliance’s excellent article.
In the effort to make agile seem familiar to customers
accustomed to traditional project plans, the Backlog is
often characterized as “the project plan for the entire
release.” Some teams — to satisfy their stakeholders’
desire to remain in the comfort zone of traditional prac-
tices — will use familiar tools such as Microsoft Project to
track the backlog, turning that tool from a task-focused
to a feature-focused device. As long as project teams can
resist the urge to start decomposing features into granular
tasks and remain focused on the delivery of valuable fea-
tures instead of task activities, I encourage this practice.
I’m resistant to making the agile migration into a cultural
tug-of-war; the more agile PMs can utilize familiar tools
without sacrificing agile concepts, the less resistance
and methodology competition they’re likely to encounter.
Tools such as ScrumWorks and VersionOne, which are
designed specifically for agile development projects, are
solid alternatives to Microsoft Project, with the added
advantage of assisting PMs in educating and migrating
stakeholders to agile terminology and concepts. What-
122
ever tool is used, agile PMs must remember the central
agile idea of simplicity and not make the Backlog more
complicated than necessary; put simply, the Backlog is a
list of features stakeholders have told us they want. Many
agile teams keep it on a whiteboard, or in Excel, or on the
wall in the form of a bunch of sticky notes. In fact, sticky
notes, which are easy to move, change, reprioritize, and
even wad up and throw away, may be the representation
of the Backlog most consistent with agile concepts.
Sprint Backlog
In agile development, each iteration reveals new realities
about the product, our processes, and the team’s capa-
bilities and speed — that’s why the Sprint Backlog is such
an integral element of the process. When we’re starting
out, the initial Sprint Backlog tells us which features,
out of all those uncovered, we’ve selected to tackle in
the first iteration. As we work through our iterations and
learn about the complexities, interactions, and realities of
development, we modify our plans to take into account
our empirical learnings about the product.
The Sprint Backlog is a subset of the Product Backlog,
narrowly focused on the features we’re trying to complete
in the current iteration, rather than the entire feature set
for the entire product. Stories to be developed in the cur-
rent sprint are selected by the team, so that they own their
commitments and are updated regularly in Sprint planning
meetings to reflect the reality of the team’s progress.
Changes Report
As we’ve learned in traditional project work, teams can
misjudge their ability to deliver or the complexity of
features for many technical and organizational reasons. In
addition, agile teams know that they, or their stakehold-
ers, are likely to think of valuable additions or extensions
to the product as they are exposed to it and have a
chance to see how it works.
Agile teams are committed to encourage and create ben-
eficial changes to the feature set in order to produce the
end result that delivers the most customer value. We also
want to avoid cumbersome change control processes that
discourage change and make every new idea seem like
a defect in requirements gathering. This is one area that
plagues agile migration projects the most, as customers
and development teams worry about our ability to control
and track changes to a project in progress.
The Changes Report is a key instrument for helping teams
and stakeholders gain comfort with the agile change
process. True, we can add, delete, or modify features
while the project is in motion, but we keep track of them
in our Changes Report, and they are always subject to the
approval of the Product Owner (in Scrum) or whomever is
designated with decision authority from the client side.
Because this report often acts as a rough traceability docu-
ment for audit or budget retrospectives, it’s probably better
suited for a spreadsheet or outline list rather than a wall
full of sticky notes. It should have enough detail to track
the change requestor and the business justification for the
change to allow stakeholders to make informed decisions.
by the comments about “Big Visible Charts” made by
agile pioneer Ron Jeffries. As agile PMs, our methods
should always support the imperative for communication
and collaboration. While conversation is the best vehicle
for encouraging clarity and relationship, charts on the wall
of a “war room” can make it clear to all who pass exactly
what the team has accomplished, what’s left, and how
you’re doing against commitments.
Summary
We’ll leave the conversation about the Daily Meeting
for another day, except to say that, of all the reporting
mechanisms of an agile team, it may be the most critical.
Agile teams should be agile in reporting as well as deliv-
ery; they can add charts for whatever they need to track,
such as defects or customer acceptance, and can aug-
ment this minimum reporting set with reports on velocity,
Net Present Value, AgileEVM, or many other status items.
Most important is to maintain open collaboration and
communication and to avoid making the process more

While not included in every implementation of Scrum, I fa- important than the product.

vor the Changes Report from bitter experience of disagree-

ment and “convenient memory” when changes requested
by clients impact schedule or budget commitments.

Burndown Chart
The Burndown Chart is a simple trend graph that il-
lustrates work performed over time. Agile teams use a
relative-size approach (e.g., story points) to estimate the
work to be done, plot the number of points developed as
time passes (beginning with the first sprint and all features
still to be developed), and draw a trend line between
these points.

A quick look at the chart also tells us how far you still
have to go; it can also indicate places where the team is
getting stuck or incorporating lots of changes. Upward-
sloping trend lines aren’t necessarily bad, as they can
indicate beneficial changes in direction, but they’re always
worth seeing. This requirement for visibility is emphasized

123
Agile drivers for new project management tools
If you believe in the concept of the tipping point, the
migration to agile software development has tipped.
According to the latest report on Agile Development Tools
by Forrester Research, 56% of the survey respondents
use agile or iterative development methods, in contrast to
the 13% who profess to using a waterfall approach (the
remainder use no formal methodology). These statis-
tics illustrate that agile has gone from a radical, fringe
technique to the dominant methodology since the Agile
Manifesto was first published back in 2001.
One of the central tenets of the Agile Manifesto is the
statement that “We value processes and tools, but we
value individuals and interactions more.” Like many of the
bold statements that make up the manifesto, this phrase
has been misinterpreted to mean that agile developers
must reject tools and automation of the development
process and that the use of any tool to assist in tracking
progress or managing tasks, other than a packet of sticky
notes affixed to the wall, automatically brands a team as
“un-agile.”
Like the extreme interpretation of the comments in the
Agile Manifesto regarding documentation, which has led
to the myth that agile developers aren’t allowed to use
pens or paper, this extreme interpretation misses the
point. When agile developers decide how much docu-
mentation to write or what sorts of tools to apply, the
guiding principle is the same: What’s the “barely sufficient”
solution that fulfills the functional need without adding
unnecessary process and without sacrificing the ideals of
simplicity and flow that guide agile development?
The tools define the project
It’s also important to remember that, for many develop-
ment teams, as well as their clients and managers, the
tools define the project. When I manage projects as
a contract PM, my clients often want to see the work
124
breakdown structure, or project plan, usually constructed
in Microsoft Project, to demonstrate to them that I’ve
thought through the tasks required to deliver the project
results. They look for the Gantt chart to see the effort
defined against a time line, and they expect to see written
change control documents when the scope evolves. For
many managers, the most difficult element of migrating
to agile is acclimating to new techniques for planning
work, tracking progress, and integrating changes into the
project scope. Often, the client’s attitude is “I don’t care
what you developers do in your ‘war room’; be as agile as
you want in your development activities, but you still need
to show me a project plan and a Gantt chart to reassure
me that you’re on track.”
The distinction between
operational and experimental
projects
In addition, it’s important to refer to the agile concepts
of experimentation and uniqueness. As Jim Highsmith
repeatedly reminds us, agile development is, at its core,
focused on fitting the process to the type of project at
hand. Operational projects that incorporate existing proj-
ect plans and produce repetitive results, like the building
of the twentieth semiconductor fabrication plant, probably
don’t require or benefit from agile methods; the develop-
ment of a new silicon chip design does.
This distinction between operational and experimental
projects is key. When we build software or products in an
experimental mode, the actual coding or development
can’t be automated or “tooled”; only human beings can
go through the iterative, speculative process of trying out
ideas, accepting or rejecting them, and following their
thread to the next unique idea. That’s not to say, however,
that every element of the agile development process is
unique. Every project sill requires design, testing, integra-
tion, and monitoring, and these common elements can be
automated and, in fact, are being automated by vendors
eager to produce the corollary of Microsoft Project for the
agile world.
Automation in agile development
In fact, contrary to the myth that agile teams reject tools,
agile development calls out for automation due to some
of its inherent characteristics. Because stories or features
are often decomposed into tasks and frequently parsed
out to different team members for development, the ability
to keep the entire team informed on the progress against
task and feature development is critical. In distributed
teams, this obviously becomes even more important.
Frequent testing and integration also drives the need for
current information that is easily accessed by team mem-
bers, so they can understand the status of all elements
of the product at any moment. As we discussed earlier,
during the migration to agile, managers are often discon-
certed by the change in status reporting tools; new tools
that can reassure them that they can still keep their finger
on the pulse of development are key reassurance factors
that go a long way toward easing the transition.
Speed and agility are factors
Both speed and agility also cry out for new tools. In an
agile project, in which features, sequences, and tasks can
change rapidly and items can be added or subtracted
from the scope daily (or even hourly), the old Gantt-chart-
on-the-wall technique won’t work, unless you want to
assign someone to put it up and tear it down hourly. Tools
that allow for frequent transitions in the plan and that can
instantly indicate what the team has learned about what
will or won’t work are required.
Agile tools
As I noted in a previous TechRepublic column, “Scrum
and Other Agile Practitioners Use Different Techniques
125
for Tracking and Reporting than Traditional Developers,”
the Product and Sprint Backlog, the Burndown Chart,
the Change Report or Delta Table, and other tracking and
monitoring tools are obvious candidates for automation.
Many vendors, from IBM and HP to newer entrants such
as CollabNet, Rally Software, and VersionOne, are pro-
ducing products that offer these capabilities, and more.
CollabNet, for example, has a suite of tools that spans the
gamut, from its free ScrumWorks Basic package (which
offers the foundational capabilities to track and manage
a product backlog) to its TeamForge product (which pres-
ents a complete team development environment designed
for large-scale, distributed development efforts).
Conclusion
This article is not intended as a review of these tools, but
instead to discuss the agile drivers and concepts that cre-
ate the need for new project management tools in the first
place. Forrester, in the report noted above, does a great
job of evaluating the many vendor offerings in this space
and guiding readers through the selection process. Many
of these vendors offer free trial versions or limited-time
trials of their complete packages.
Agile teams need to discard the myths that fool us into
believing that we must either adapt the old tools or use
only whiteboards and Post-it notes to control our project
efforts. The agile tool space is populated with mature, ca-
pable tools that can make the work of agile development
more efficient and visible, without violating the fundamen-
tal tenets of agility.
Get an overview of the Scrum agile
project approach
In previous columns, I discussed various concepts cess and then disengages until the end product
regarding the application of agile project management is delivered.
methodologies, from estimating to the discovery of
Mary Poppendieck, in her introduction to Ken Schwaber’s
requirements. I’ve mentioned some of the variants of agile
book Agile Project Management with Scrum, makes a
methods, such as Extreme Programming and Adaptive
very apt analogy. She compares traveling by airplane with
development, but I have yet to explore the specifics of any
traveling by car. Air travel, while convenient and appropri-
of the agile approaches. So let’s take a more focused look
ate for certain types of trips, such as those in which the
at the agile variant that is gaining a lot of traction: Scrum.
origin and destination are well-known and unchanging,

Fundamentals of Scrum
Scrum is an example of a structured agile methodology
that, by applying a few simple “rules of the road,” enables
teams and their clients to develop complex, innovative
products by entrusting them to use their talents and intel-
ligence to devise their own direction.
Like all the agile approaches to software development
and project management, Scrum builds on a few funda-
mental concepts. The concepts are:
In experimental or exploratory projects, predic-
tive methods are less likely to be effective than
incremental, iterative approaches that present
the client with progressive deliverables and then
make adjustments and course corrections as the
work proceeds.
Teams of self-motivated, skilled practitioners are
more likely to succeed and to feel rewarded and
productive in self-directed teams in which
individuals take ownership of specific deliver-
ables and then devise their own methods of
achieving them.
Constant and close collaboration with the client
and sponsors of a development effort is more
likely to succeed than projects in which the client
participates in a front-loaded requirements pro-
prescribes every element of the trip with detailed check-
lists and procedures and requires a central control agency
to direct every decision and procedure. Traveling by car,
in contrast, allows the traveler, by following a few simple,
well-understood rules, to determine the route as she
goes, to make adjustments and decisions on the fly, and
to explore byways and detours that may add significant
value to the trip and the outcome.
The point of the analogy is that, while predictive and
rigidly controlled processes are totally appropriate for
trips in which the path is well-known, few new discoveries
are expected, and predictable outcomes are essential.
For those trips in which discovery and exploration are the
goal, independent actions by operators making decisions
as they go and applying a few simple “rules of the road”
are more likely to deliver satisfying results. “Some might
try valiantly to make control systems work by applying
more rigor,” Poppendieck notes, “…but the people who
prevail are those who figure out how to change to a sys-
tem of independent agents operating under an appropri-
ate set of rules.”
In action, Scrum is based on a few simple rules, roles, and
artifacts. Through the independent, self-directed applica-
tion of these rules, roles, and tools, talented teams try out
their ideas, present them to the sponsor for comment and
validation, and, based on the new information generated

126
by that interaction, refine their course until they deliver and barriers is a key element of the ScrumMaster’s role.
what the customer wants. This data-driven approach to
Product owner
product development is the foundational idea of Scrum
The second role is that of the product owner, who is
and of all agile methods.
responsible for defining the product’s features and func-

Three key roles in Scrum tions, for collaborating with the ScrumMaster and the

The number three plays a central role in Scrum. There are development team to review each iteration and determine

three key roles in a Scrum effort, three key activities or the product’s suitability, and for working with the team to

“ceremonies” that participants perform, and three central adjust, modify, and reprioritize the feature set based on

artifacts or tools that Scrum teams use to organize and business needs, market conditions, ROI expectations,

track their work. Let’s take a look at the roles first.
The three central roles in a Scrum effort are: the Scrum-
Master, the product owner, and the development team.
and technical hurdles that arise. Scrum teams take the
idea of “ownership” seriously; the designated product
owner is the ultimate authority in deciding if the work
results, either interim or final, are acceptable.

ScrumMaster Development team

The ScrumMaster plays the role that a project manager
The development team organizes itself and the required
would take in a traditional project, but the responsibilities
effort to deliver the results and collaborates both inter-
and approach are quite different. Rather than behaving
nally and with the product owner and his colleagues to
as a project foreman, supervising the daily tasks of each
determine the feature set, to segment it into sprints, and
contributor, or as a project bureaucrat, recording
to perform the actual development of the work product.
progress in project plan and Gantt chart, the
Most importantly, the team decides for itself how to per-
ScrumMaster is a facilitator, collaborating with the
form the work and deliver the results. Unlike a traditional
product owner to define the project goals and to enable
project, the work is not parsed out into granular tasks for
the Scrum team to work toward those goals in the most
the team; the team and its members determine for them-
productive way. The ScrumMaster spends his time as a
selves who will take responsibility for each feature or story
facilitator, a coach, and a collaborator, sheltering the team
and how they’ll tackle the development activities.
from barriers,
interference, and external politics and leading them Stay tuned
through the Scrum practices and activities toward the Next time, we’ll look at the “ceremonies” and the artifacts
successful delivery of the best result. that Scrum teams apply.

Like the project manager in a traditional environment, the

ScrumMaster must know the status of all the features
that the team has uncovered in the requirements or story
exercise and must maintain the Burndown chart to reflect
the current state of development. The ScrumMaster also
must focus on any political, cultural, or personal
impediments that might derail or delay the effort. Whether
the issue is a client participant who isn’t available as
promised for collaboration or a team member whose skills
are not as expected, the resolution of problems, conflicts,

127
Take positive risks to gain project benefits
Risks are future events or conditions that have some technology were guaranteed, we could make the
probability of occurring and that will some impact on your decision to move forward with 100% confidence.
project. We usually think of risks as being bad and we try However, usually the benefits are not guaran-
to put a plan in place to make sure the risk goes away. teed. The technology, or our implementation of
the technology, could turn out bad, in which case
But are all risks really bad? Let’s say your project was go-
we might be worse off than when we started.
ing to utilize a new tool or new technology. Would it make
sense to you if I said that your project was riskier than a Positive risk is also called “opportunity risk.” In these
similar project that is using current technology? instances, the project manager or project team may intro-
duce risk to try to gain much more value later.
On the surface this would seem to be correct. Your team
probably understands the current technology better, A key aspect of positive risk is that you put yourself in a
the current technology is probably more stable and you position to take on the risks; they are risks that we know-
probably have a lot more support infrastructure. The new ingly take upon ourselves because we perceive there to
technology is not understood as well, has more oppor- be advantages to doing so.
tunity for problems and you don’t have nearly as solid of
Different organizations have different tolerances for risk.
a support infrastructure in case something goes wrong.
Remember that all risks have a probability of occurring.
Even without understanding the specific technology in
They’re not guaranteed. If you take an intelligent risk
question, it makes sense that projects with new technol-
and you fail, what happens? If your organization rewards
ogy would be somewhat riskier that a similar project that
people who take risks and are successful, and they
uses current technology. (I know there are exceptions, but
punish people that take risks and fail, then they are really
this is generally true.)
risk averse.
So here’s the question: If it’s true that all projects are
Generally when we’re doing risk management on projects,
generally more risky when we use new technology, why
we’re talking about potential negative events. However,
would you ever undertake a project with new technology?
you can also identify the risk events that lead to posi-
The answer, of course, is that we perceive there to be a
tive outcomes. Your risk plan should include activities
benefit to our project. In other words, the potential impact
designed to give you the best chance that the risk event
to our project is a positive. This still meets our definition
will come true.
of risk.

There is an impact to our project. Normally risk

events have a negative impact on our project.
However, with positive risk there is a potential
positive impact.

There is a probability of the event occurring.

This is still the case with positive risks. In our
prior example, if the benefits of moving to new

128
Find errors as early as possible on your project
Project teams generally use three types of quality man- solution again. As you can see, this is a potentially huge
agement activities: impact to your project.

Quality planning Likewise, if you were manufacturing a computer chip, it

would be much cheaper to find a problem with a com-
Quality control
puter chip when the chip is manufactured, rather than
Quality assurance have to replace it when a customer brings the computer
in for service after a purchase. In fact, if the error isn’t
The purpose of quality assurance is to prevent as many
caught until after the chip is sold to the customer, the cost
errors as possible by having sound processes in place to
to make the repair might cost more that the entire cost to
begin with. The purpose of quality control is to inspect or
manufacture the product to begin with.
test the deliverables to find as many remaining errors as
possible. There was a project early in my career that applied poor
shortcuts to the development process. Since the pro-
One important aspect of quality control is to find errors
grammers were under time pressure to complete their
and defects as early in the project as possible. Therefore,
modules, they figured they would write the code and
a good quality control process will end up taking more ef-
make sure it compiled cleanly. Then they would then call
fort hours and cost upfront. However, there will be a large
the module complete, with the attitude that they could “fix
payback as the project progresses.
it in the testing phase.” They thought that they were just

For instance, it’s much better to spot problems with deferring their unit test time until later in the project. But

business requirements during the analysis phase of the by pushing these errors further downstream, it actually

project rather during the testing process. If you see the took much longer to fix the problems later - to the detri-

problem during the requirements gathering process it ment to the overall project.

might just take a call to your client and the quick update
In Figure A, we see a traditional approach to finding errors.
of a Word document to fix it. On the other hand, if you
In Figure B we see the better approach. It is much better
discover this problem in the testing phase, it could impact
to catch any errors that are introduced as quickly as
the business requirements, the solution design, and some
possible. In other words, errors in the deliverable cre-
of the construct work. It will also require you to re-test the
ated in the Analysis Phase
should be caught in the
Figure A
Analysis Phase; errors
introduced in the Design
Phase should be caught
during the Design Phase,
etc. This greatly minimizes
the impact of correcting the

On many projects the team plans to find as many errors as possible during the testing process, errors.
with some errors not caught until support/maintenance.

129
The bottom line
Figure B
is that the project
team should try
to maintain high
quality and low
defects during the
deliverable creation
processes, rather
than hope to catch and fix problems during the testing
phase at the end of the project (or worse, have the client
find the problem after the project has been completed).

130
Inadequate quality management will result
in project problems
Poor quality management can stand in the way of a is required because the original construction and testing
successful project. The two keys to avoiding lapsing process was not thorough enough and errors still existed
into substandard quality management are to remember, in the deliverable.
first, that the project sponsor and your client determine
Higher maintenance and
quality—the project manager and project team do not.
support costs
And, second, you need to resist the urge to think that
If errors are caught within the development process, there
quality means the best material, the best equipment, and
is a cost associated with rework. However, many times
absolutely zero defects. In most cases, the client does not
quality problems surface after the project deliverables are
expect, and cannot afford, a perfect solution. If there are
completed and in production. This situation just hands
just a few bumps in the project, the client can still say that
the problem off to the support organization. High support
the project delivered to a high level of quality.
costs from a poor quality solution are a sign that the team

On the other hand, a flawlessly designed, defect-free willingly delivered a less-than-acceptable solution, or else

solution that does not meet the client’s needs will not be it did not realize the poor quality because the team’s test-

considered high quality. The purpose of quality manage- ing process was also inadequate.

ment is to first understand the expectations of the client

Client dissatisfaction
in terms of quality, and then put a proactive plan and
If a solution is of poor quality, the client will not be happy.
process in place to meet or exceed those expectations.
Some of this unhappiness may be transferred to the sup-
Here’s how to do just that.
port organization. However, if the client has a choice, it

Heed the signs may not buy from you again at a later date.

Problems with quality show up in a number of areas. For

Missed deadlines and budget
instance:
In many cases, projects that do not manage quality well
end up with a lot of rework, which in turn leads them to
Rework
miss their deadlines and exceed their budget. This can
This is the primary problem caused by poor quality work
cause the business value to be delayed, or it may change
during a project. Rework means that you have to do the
the value proposition for the entire project.
same work twice because the original effort was not
satisfactory. For example, let’s say your team has created
Poor morale
a software component in a large application. Component
No one likes to work for an organization that has poor
walk-throughs or peer reviews are not considered rework,
processes or produces poor quality solutions. No one
since they are part of building the component the first time.
likes to work on projects that are missing their deadlines

When you say the component is complete, the hope because of rework. People tend to find excitement and

is that no more work is needed. However, if there are challenge in building a solution. However, the team’s

subsequent errors when your component is tied into the motivation level will go down when it has to continually

larger application, rework is required. This is work that repair and rework deliverables that don’t work correctly.
In addition to poor morale in general, specific costs can

131
include increased absenteeism, higher turnover, and less ensure that work is completed with a minimum amount
productivity from the staff. of errors—the first time around. The project manager
and team need to understand that the first goal of quality
What can be done?
management is to produce deliverables with no errors. The
Quality management is not an event that you consider
second goal is to catch any errors as early as possible.
once in a while. Quality management is an ongoing
process that the team needs to focus on throughout the From a practical standpoint, if you can build the deliver-
project. When the project begins, the project manager ables with as few errors as possible, and then find those
should prepare an overall Quality Plan containing these remaining errors as early as possible, your overall project
three major components: will have much fewer problems. Quality problems tend
to show up late in the project—usually during the testing
1. Criteria for completeness
and correctness process. However, if you have a good quality process in
place, testing should only confirm that everything is work-
I said earlier that quality is determined by the client, not
ing correctly. Then you can work quickly toward final ap-
by the project manager. That might make the project
provals, implementation, and a smooth production cycle.
manager uneasy, since he or she may not be sure of the
client’s expectations. That is where completeness and
correctness criteria come in. The project team and client
then have a common expectation of what is required for
each deliverable to be accepted.

2. Quality control process

Quality control refers to the ongoing activities that the
project team will perform to ensure that the deliverables
are of high quality. This can include deliverable walk-
throughs, testing of subcomponents, completeness
checklists, and so on.

3. Quality assurance process

These are the activities designed to ensure that the overall
processes used to create the deliverables are of high
quality. These types of activities include third-party audits,
checklists to ensure that all parts of a process were com-
pleted, and deliverable approvals.

Everyone on the team needs to have a quality mindset to

132
Microsoft Project 2007 4
Add a custom report in Microsoft Project 2007
Microsoft Project’s scheduling engine is full of data 1.
ranging from activity field definitions to earned value
management calculations. You can access a lot of the 2.
information using Microsoft Project’s tables and views; 3.
however, printing this information can be tedious as you
4.
try to fit all the columns on one screen. A better option is
to use Microsoft Project’s reporting features.
Go to Report | Reports from the main menu
(Figure A).
Click the Custom icon.
Scroll down and click the Task report (Figure B).
In the Task Report dialog box, click Copy and
rename the Name field to Behind Schedule
Report (Figure C). (Keep the Table: Entry since

Microsoft Project comes with a lot of reports categorized you copied it from the original Tasks report.)

by activities, costs, assignments, and workload. I’ve used 5. Change the Filter to the Behind Schedule filter
the delivered reports for summary level information, but and click OK (Figure C). If you don’t see the
I find it more useful to create
my own set of custom reports Figure A
to answer specific key ques-
tions. Here’s how to generate
a custom report based on an
existing filter.

This tutorial features the Behind

Schedule filter that we created in
a previous column to develop a
Behind Schedule Report. In this
report, I want to identify the late
tasks and identify the responsible
resource. Instead of creating
Figure B
a separate view, I want the report to list the Task ID,
Task Name, Start, Finish, Baseline Start, Baseline
Finish, and Resource Name columns. Once I print the
report, I’ll distribute it to my teams and include it in my
status report packet.

Create a custom report based

on an existing filter
First, you need to create the Behind Schedule filter in
Microsoft Project 2007. When the Behind Schedule
filter is complete, open the Report dialog box.

133
 Behind Schedule filter in the drop-down list, go
Conclusion
back and create it.
In my recent TechRepublic tutorials, I demonstrated how

You can choose any table or filter to meet your criteria. I you can customize Microsoft Project to identify late tasks

recommend finding a report that contains the base data using filters, graphical indicators, and reports. The key

elements, following the same copy report process, and takeaway from these articles is to use Microsoft Project’s

applying the appropriate filters. default tables, view, and filters to answer commonly asked
questions when managing a project schedule. By adding a
Remember that the Baseline Schedule filter requires a
few custom reports, filters, and indicators, it can help you
project baseline to be set in order for the filter to compare
interpret the schedule data in your project schedule.
the status date to the original baseline.
When sharing information with the immediate team or
Run the report project stakeholders, I find that using the custom reports
To run the report, go to Report | Custom, select the Be- approach is better than trying to print specific views from
hind Schedule Report, and click the Preview button. The Microsoft Project. By developing different views and re-
report will prompt you for a status date. Enter the status ports, you can quickly identify late tasks, unstarted tasks,
date, and the late tasks will display in a report format or tasks assigned to specific resources. If you have a PDF
(Figure D). driver like pdf995 installed, you can also print the report
as a PDF and distribute it.
If you want more columns in the report, you need to add
the specific columns into the Entry table. In the
Figure C
report example, I added the ID, Task Name,
Start, Finish, Baseline Start, Baseline Finish, and
Resource Names columns. I hid the % Complete
and Duration columns because the information is
supplemental.

Figure D

134
Add the Late Indicator tool in
Microsoft Project 2007
One challenge in reviewing project schedules on a weekly project status date in Microsoft Project, the graphical indi-
basis is quickly identifying late tasks. In previous tutorials, cator will quickly identify all the late tasks in your sched-
I showed how to build the Behind Schedule filter and how ule as well as the tasks that are not behind schedule.
to use the Slipping Tasks filter. Here’s another approach
To build the Late Indicator, follow these steps
to identifying late tasks: using a graphical indicator. This is
a useful way to review all the project tasks in one view and 1. Select Tools | Customize | Fields.
use a graphical indicator to show if a task is on or behind
2. In the Type combo box, select the Number value.
schedule. (This tutorial is specific to Microsoft Project 2007.)

3. Select an unused Number field (i.e., Number1,

Late Indicator Number2, Number3).
The Late Indicator (Figure A) is based on a simple cal-
culation that looks at all incomplete tasks and compares 4. Click the Rename button.
the Baseline Finish Date to the Project Status Date. Like
5. Enter Late Indicator in the Rename Field (Figure B).
the Behind Schedule filter, the tool compares the project
baseline against the weekly project status date. Note: If 6. Click the Formula button.
you don’t manage the project schedule using a Baseline
7. Enter this formula:
Plan, this graphical indicator will not work. (If you don’t
use a Baseline Plan to manage your projects, I hope this IIf([% Complete]<>100,DateDiff(”d”,[Baseline
tutorial inspires you to do so.) Finish],[Status Date]))

Once a project baseline is set and you record your weekly The formula (Figure C) examines all incomplete tasks and

Figure A

135
compares the Baseline Finish Date to the Project Status At this point, a custom field has been modified with a for-
Date field. If a task is incomplete, the difference between mula that displays a graphical indicator. The next step is
the two dates will be reported. to insert the Number field into your Gantt Chart view and
set the Project Status date. In my example, I modified the
Late Indicator Formula
8. Click OK. Figure B

9. In the Values to Display section, click

the Graphical Indicators radio button.

10. Enter the following tests, values, and

images from the drop-down boxes
(Figure D).

11. Click OK twice.

Figure C

136
Number2 field and, to add it to my current view, I selected
Insert | Column and selected the Number2 (Late Indicator)
field from the Field Name drop-down menu. The last step
is to update the project status date.
12 Select Project | Project Information (Figure E).
13. Select the Project Status date from the drop-
down calendar.
Once the Status Date is set, the graphical indicator will
“light up” and identify the late tasks with the red bulb in-
dicator. Remember that you’ll need to update your project
progress weekly and change the status date accordingly.
As the project progresses, the indicators will change.
When a task is completed, the indicator will disappear as
the indicator looks only at incomplete tasks.
Summary
Microsoft Project can present an overwhelming amount
of data with its different views and underlying data tables.
I find it useful to include graphical indicators in a project
schedule so anyone viewing it can quickly determine if there
are tasks running behind schedule. It can also be used in
your status reporting by applying the Milestones filter.
Go ahead and experiment with the different formulas and
graphical indicators available in Microsoft Project. In a
future tutorial, I’ll share a few more useful formulas and
graphical indicators that help improve status reporting.

Figure D

Figure E

137
Identify slipping and unstarted tasks with
Microsoft Project filters
In a previous Microsoft Project tutorial, I showed how
to identify late tasks using the custom Behind Schedule
filter. Identifying late tasks is just one useful action that
PMs should conduct weekly. If you’re examining behind
schedule tasks, then you’re already on your way to
actively managing your plan.
Another important schedule management activity is to
examine any unstarted tasks, late starts, and slipped
tasks. By examining tasks that haven’t started yet or tasks
that are forecasting past their baseline start date, you
will identify any work that is shifted to future dates. If you
don’t watch for the shift in your project schedules, you risk
missing deadlines. Fortunately, Microsoft Project provides
useful filters to identify slipping tasks and unstarted tasks.
Slipping Tasks filter
The Slipping Tasks filter is a pre-built Microsoft Project
filter that identifies all the tasks that haven’t started and
have a forecasted finish date that is greater than the
Baseline Finish date. This filter will identify the shift in your
project schedule and list all the unfinished and future tasks
that have been extended past the Baseline Finish date.
To view the Slipping Tasks filter, in the Formatting toolbar,
select the Slipping Tasks filter from the Filter combo box
(Figure A).
In the project schedule in Figure B, the Use Case 1 task
had a Baseline Start date of 4/15/2010 and a Baseline
Finish date of 4/19/2010. The task is in progress and has
an Actual Start of 4/20/2010 and a Forecasted Finish of
4/22/2010. This represents a shift of three days from the
original project schedule. The project manager needs
to determine if the shift impacts the critical path and its
impact to project milestones.
All of the Interface tasks haven’t started, but those tasks
also inherit the three day shift from previously completed
tasks and work in progress. The project manager needs
to determine if the variance is acceptable or if additional
action is required to realign these tasks with the original
baseline start dates.
To clear the Slipping Tasks filter, select the All Tasks filter,
and all the tasks will be displayed. The All Tasks filter

Figure A

Formatting toolbar - Slipping Tasks

Figure B

Slipping Tasks filter applied.

138
is useful only if the project manager has an established
project baseline and actively tracks actual start and
finish dates. I’ve seen several project schedules where
the project manager uses the schedule as a task list and
only tracks percent complete. If the project manager
doesn’t update the actual start date or provide an update
to forecasted finish dates, the schedule will always match
the baseline. In this case, the filter will be useless. To avoid
this situation, I recommend you track your project schedule
objectively.
Unstarted Tasks filter
The Microsoft Project pre-built Unstarted Task filter identi-
fies all the tasks that have not started; this technically
means the Actual Start date for each task is equal to NA.
This includes all tasks in your schedule including future
scheduled tasks. I use this filter frequently so I can filter
on the Baseline Start Date to identify all the tasks that
should have started by the given project status date.
Figure C
Custom Baseline Start AutoFilter
Figure D
Tasks that should have started by the project status date
To identify all the tasks that haven’t started as of the
project status date, follow these steps:
1. Insert the Baseline Start column into your view.
2. Select the Unstarted Tasks filter from the Filter
combo box in the Formatting toolbar.
3. Using the Auto Filter button, create a Custom Auto-
Filter where the Baseline Start Date Is Less Than
Or Equal To Your Project Status Date (Figure C).
The result is a list of tasks that should have started by the
project status date (Figure D).
Summary
By tracking your unstarted tasks and behind schedule
tasks, you’ll have a good idea of the tasks that need
action and follow up with the project team members. You
should expect to see a few schedule slippages, as the
baselined project schedule is a point in time forecast and
every task doesn’t execute perfectly according to the
project schedule.
The key takeaway is to look at the
Baseline Start and Baseline Finish
dates and compare those dates to
the current Start and Finish dates
and examine the variances. Then the
real “fun” begins as you look to re-
align the slipped work to the original
project baseline.
139
Importing a vendor’s Excel schedule
into Microsoft Project
For the past four years, I’ve worked for companies that
outsource the majority of their IT work to external vendors
using fixed-price contracts. One challenge in jointly de-
livering a project with an external vendor is obtaining the
vendor project schedule in a format that can be integrated
with Microsoft Project.
The obvious solution is to have the vendor provide its
Microsoft Project schedule; the reality is some vendors
are reluctant to hand over their detailed schedule because
it contains cost data, notes, custom macros, and other
private data. If you’ve worked with outsourcing vendors,
then you’re familiar with some vendors who don’t consis-
When you export data from Microsoft Project into Excel,
the data file doesn’t maintain the hierarchy. Creating the
hierarchy in Excel usually involves grouping and indenting
in Excel or using a custom macro to build the hierarchy.
When you import an Excel file into Microsoft Project, it
also lacks any of the indenting (Figure A) and summary
tasks that make Microsoft Project a valuable roll-up tool.
Building the import map
My solution was to develop an import map that includes
the key fields in Figure B.
To build this map in Microsoft Project, follow these steps:

tently use Microsoft Project as a scheduling tool. 1.
In my case, I typically receive an Excel file with tasks
and start and finish dates. Ironically, my vendor extracts
this information from his Microsoft Project schedule and
2.
provides an Excel file that I can scroll through to find key
3.
milestones and due dates. Faced with the poor usability
in scanning hundreds of tasks using Excel, I developed an
import map that will properly import the Excel sheet that 4.
Open a sample Microsoft Project schedule. (It
helps if you have a completed project schedule
so the final export will have meaningful data.)
Go to File | Save As.
Select the Microsoft Excel Workbook (*.xls) as
the Save as Type and click Save.
Click Next and leave Selected Data as the option.

builds the task hierarchy in Microsoft Project.

5. Click New Map.

Figure A

Microsoft Project Excel import without task hierarchy.

140
 6. Select the Tasks checkbox 8. Click the Next button.
(Figure C).
9. Click Save Map and Save It as Excel MPP Map.
7. Click the Microsoft Office Project field and select
10. Click the Finish button.
the fields in Figure B.
The Excel extract will now contain the key

Figure B fields needed to build the project hierarchy.

In this case, I had to build the export map for

the vendor so they could simply export their
Microsoft Project data into a format that I
could use to import the file. Once the vendor
had this map in their Microsoft Project file,
the vendor could easily save an Excel file
using this extract. It ensured the vendor’s
confidential data was kept confidential, while
the critical data that I needed to understand
milestones and start and finish dates for key
tasks could be imported into my Microsoft
Project schedule.

Once the vendor provided a file using

this format, their schedule could easily be
imported into Microsoft Project by following
Figure C these steps:

Export Wizard - Task Mapping

141
 1. Start Microsoft Project with a blank project schedule as a new project; I ran into calculation issues
schedule. because the % Complete field is a calculated field and

2. In Microsoft Project, go to File | Open. didn’t consistently convert.

3. Change the Files of Type combo box to Microsoft Applying these concepts to other
Excel (*.xls). schedules
4. Select the extract file and click Open. You can apply these same map concepts to other sched-

5. Click the Next button. ules that lack the Outline Level, but you’ll need to build
the Outline Level manually. Depending on the level of
6. Select Use Existing Map.
granularity required, you might just want the vendor’s key
7. Select the Excel MPP map. tasks and milestones instead of the entire project sched-
8. Select Append the Data to the Active Project ule. The main benefit is that once you have the vendor and
(Figure D). your project activities defined in one integrated view, you
can easily identify late tasks and analyze the critical path.
9. Click the Next button.

10. Click the Next button. In fixed-price outsourcing projects, you may outsource
the work to another supplier and establish penalties for
11. Click the Finish button.
failing to meet milestones. From a financial viewpoint, it
The end result is a properly formatted Microsoft Project
makes sense because a fixed-price contract puts all the
file that contains the vendor’s project schedule. Once the
risk on the vendor; however, effective project managers
schedules are converted, I insert them as subprojects in
collaborate with all their team members (vendors, custom-
the master project schedule.
ers, and internal team members) to deliver their projects.

Before I came up with this solution, I would import the A key to being a successful PM is tracking to an inte-
grated project schedule so the team can collectively
Figure D understand progress.

If the vendor can’t provide all their

schedule data, this Excel MPP
map will help integrate the data
you need.

Import Wizard - Import Mode

142
Identify late tasks with this custom
Microsoft Project filter
When managing a project schedule of even a moderate Finish date where the Baseline Finish Is Less
size, it’s valuable to be able to quickly identify late tasks Than Or Equal To a given status date (Figure B).
without scrolling through a large hierarchy of tasks. In
The resulting schedule identifies all the tasks that haven’t
Microsoft Project, you can identify incomplete, late, or
finished and can be filtered by resource (Figure C).
slipped tasks by using one of these options:
This approach worked to generate a list of late tasks for
Tracking Gantt view
project status reviews; however, once I switched views
Incomplete Tasks filter or needed additional information, I had to remove the

Late Tasks Assigned to Resource filter filter and then rebuild it a few minutes later. This process
quickly became tiresome to simply view late tasks. The
Slipped/Late Progress filter
need for a quick and reusable filter to identify tasks that
These built-in filters are nice, but I
usually need to filter on a different
Figure A
set of criteria to view the data I like
to see. So I decided to create a
custom filter in Microsoft Project
that would identify late tasks.

Rethinking my first
approach
My original approach was to iden-
tify a late task by filtering on the %
Complete field, the Baseline Finish,
date, and the Resource name % Complete filter

column. I followed these steps:

Figure B
1. Select the Tracking Gantt
View using the Entry
Table.

2. Insert Baseline Start and

Baseline Finish.

3. Confirm the % Complete

column is in the view.

4. Filter on the % Complete

column (Figure A).
Baseline Finish filter
5. Filter on the Baseline

143
were behind schedule led me to create a custom filter that 4. Enter “is less than or equal to” as the test
I named Behind Schedule. condition.

5. Enter “Status Date:”? into the Value field (Figure

Creating the Behind
D). (It is important to enter the question mark
Schedule filter
after the quote value, as this represents a pa-
You can create your own custom Behind Schedule filter
rameter. The text entered between the quotation
by following these steps:
marks is the actual text that will appear in the

1. Select Project | Filter For| More Filters and click New. dialogue box.)

2. Enter “Behind Schedule” in the Name field.

6. Click the second row and select the %
3. Click the first row in the Field Name and select Complete field.
the Baseline Finish field.

Figure C

Late tasks using Auto Filter

Figure D

Behind Schedule filter

144
 7. Select the “does not equal” Test condition
Three key points about
and enter 100% as the value in the Value column.
using the filter
8. Click the OK button (Figure E). 1: Remember to baseline.
In order for the filter to work, you need to base-
Using the Behind Schedule filter line (gasp) the project schedule. If project teams
To use the filter, click the Behind Schedule filter in the are hesitant to baseline the entire schedule, you
Formatting toolbar and select the Project Status date. should apply a rolling planning approach and
The filter will identify any incomplete tasks based on a baseline the tasks for the next phase or major
selected date (Figure F). milestone.

To clear the filter, click the All Tasks in the Filter combo 2: Look at Slipping Tasks.
box, and all the project tasks will display. The Behind Schedule filter identifies only tasks
that are incomplete and have exceeded the

Figure E

Building a custom filter

Figure F

Late tasks using the Behind Schedule filter

145
 baseline finish date. I encourage you to also look To add a custom filter to your Global.mpt file, select Tools
at the Slipping Tasks and Slipped Tasks\Late | Organizer | Filters, select the Behind Schedule filter, and
Progress to identify tasks with impacted start click the Copy button (Figure G).
dates.
Conclusion
3: Add the filter to your Global.mpt file for future
You can create additional filters based on your criteria by
projects.
following the steps outlined in this tutorial.
The Behind Schedule filter that you created is
a local filter that is available only in the current
.mpp file. If you want this filter to be available
for all your projects, you need to add the filter
to your Global.mpt file, which contains all the
custom objects for your Microsoft Project files.

Figure G

Adding the Behind Schedule filter to Global.mpt

146
Scheduling project uncertainty
with LiquidPlanner
Project managers spend a lot of time attempting to
LiquidPlanner: A unique way to
develop the perfect project schedule with bottom-up
handle project scheduling
estimates. Despite all the upfront planning with well-
I have been looking for an alternative to my current
defined single point estimates, projects still experience
approach for scheduling uncertainty, and I was pleased
schedule slippage, late tasks, and unwelcome surprises,
to learn about LiquidPlanner. This Web-based project
as uncertainty occurs throughout project execution.
scheduling and collaboration tool will likely change the

A typical approach to scheduling uncertainty is to add time way PMs think about project scheduling.

buffers at the task or phase level that expand the project

I recently interviewed Charles Seybold, CEO of Liquid-
duration and provide enough “cushion” for you to handle
Planner, to discuss managing uncertainty in a project
unknown project delays. This approach works as long as the
schedule. According to Mr. Seybold, “Unmanaged uncer-
amount of uncertainty doesn’t exceed the project buffers.
tainty is the silent killer of projects. The good news is that

When PMs communicate dates, they often use absolutes, it’s not hard to manage uncertainty once you can visualize

which don’t allow for fluctuation based on a best case or it. The easiest way is to build that insight from the bot-

a worst case estimate. Although PMs try to forecast the tom up with ranged estimates and a realistic scheduling

future, they haven’t invented a project tool to predict the method, which is exactly what LiquidPlanner does. To put

future. Consequently, it makes sense that we should start it simply, you can’t manage what you can’t see.”

planning and communicating our schedules by incorpo-

How it works
rating uncertainty.
Instead of selecting a specific date to complete a task,
LiquidPlanner uses a ranged estimate that allows you to
specify a best case and a worst case duration estimate.
Then, LiquidPlan-
Figure A
ner’s scheduling
engine applies sta-
tistics to determine
the probability of
completing a task
by a given date
(Figure A).
Instead of specify-
ing a single point
duration estimate,
you can enter a
best case and
Sample project schedule with ranged estimates
a worst case

147
estimate, and the scheduling engine will calculate the
duration ranges with task completion confidence levels.
In Figure B, a given task’s duration will have a best
case early start, a best case finish, an expected finish,
and a worst case finish based on a probability calcula-
tion. Based on the calculations, the software forecasts a
recommended promise date with a 98% confidence. As
the project progresses, the duration date range will adjust
and, if promise dates are passed, the system will auto-
matically alert the project stakeholders.
Useful features
I built a sample schedule using LiquidPlanner’s free 30
day trial, and I found it very easy to build tasks in a project
schedule. Also, LiquidPlanner’s implied dependencies
were useful for developing a project schedule; instead of
adding explicit dependencies between tasks, LiquidPlan-
ner assumed the subsequent task was dependent upon
the predecessor. In a waterfall project schedule, this fea-
ture is useful, as resources and task start and finish dates
automatically adjust based on the order of the tasks. In
situations where the order doesn’t always imply a depen-
dency, you can explicitly define predecessors with a few
mouse clicks and create a chain of dependent tasks.
Another useful feature in LiquidPlanner is the dynamic
resource management; as resources were assigned to
tasks, the dates automatically adjusted and displayed the
probabilistic completion dates for the entire project. You
Figure B
Task Duration Bar with probability ranges.
148
don’t need to resource level the plan since Liquid Planner
automatically performed the calculations. The project end
date also didn’t unrealistically expand, as the date range
provided a best case and a worst case completion date
for the project.
Tool is consistent with
expert advice
In Neal Whitten’s book No-Nonsense Advice For Suc-
cessful Projects, he writes about applying rolling planning
and only committing to a milestone date a few weeks in
advance. He advises against committing to a launch date
months in advance when priorities can change. As the
team accomplishes the milestone, then they
commit to the next milestone date. LiquidPlanner sup-
ports this approach by providing the PM a promise date
and a range of probably completion dates instead of rigid
dates that were established months ago without
incorporating uncertainty.
Benefits of ranged estimates
For the traditional PM, the LiquidPlanner approach is
a variant to the PMBOK standard of activity definition,
sequencing, resource allocation, and duration estima-
tion. However, PMs will quickly see how useful ranged
estimates can be in planning a project and communicat-
ing a project end date with a confidence range instead
of an explicit date. The ranged estimating approach also
relieves some pressure from the project team to be 100%
correct in their estimating and encourages the team to
plan for change. LiquidPlanner helps teams visualize
uncertainty, and PMs can do a better job of planning for it
once they see the potential impacts.

Additional information
I encourage you to visit the LiquidPlanner site, sign up for a
free 30 day trial, and watch the company’s training videos.
In a future article, I’ll explore some of LiquidPlanner’s col-
laboration features that also help effective project delivery.

149
Considerations when integrating
Microsoft Project and PPM solutions
You can integrate and update a Microsoft Project sched-
ule with a project portfolio management (PPM) tool
such as CA Clarity or Microsoft Project Server. By doing
so, you can achieve resource management, schedule
management, time keeping, and objective project and
portfolio metrics. When you incorporate standard report-
ing templates and integrated project schedule data, you
quickly obtain a standardized view of the projects execut-
ing across the portfolio using real-time data.
When I first heard about Microsoft Project integration with
PPM solutions, I thought it must be the fastest way to
achieve transparency between the top-down scorecard
hungry portfolio managers and the project teams per-
forming the work. After spending several years managing
programs with these solutions, I’ve found that there are
multiple approaches and things to consider. For instance,
some project teams may prefer to publish a complete
resource constrained project schedule, while others may
prefer to incorporate a milestone only plan.
Schedule detail
I find it useful to determine the level of schedule detail
required to support Microsoft Project and PPM integra-
tion. In order to make that determination, you should ask
yourself the following five questions.
1. Do all team members agree to
use the PPM tool?
Project teams may comprise of business SMEs, external
vendors, and stakeholders outside of the core team; if
these team members are assigned tasks on the project
schedule, they will need access to the tool to provide
updates, record issues, and respond to action items.
In complex projects and programs with multiple vendors
and business customers, each camp of stakeholders will
have their own processes and reporting expectations.
150
For instance, a vendor will use their own PPM tool, while
providing input into the client’s project management
reporting process.
Establishing how the different PPM tools will be used can
help determine how to manage issues, risks, and
schedule management in a PPM tool.
2. Do all team members have
network access and licenses to
use the PPM tool?
A PPM solution that is limited to the project manager falls
short of the collaborative project benefits that a PPM sched-
uling tool provides. All team members who need to update
the project schedule, the issue repository, and the risk regis-
ter will need network access and licenses to use the tool.
Depending on your company’s budget, allocating licenses to
every project team member assigned to the schedule could
be a costly initiative. If your project uses external vendors, the
vendor may not even have network access to use the tool.
3. Will all team members exist
as resources in the tool?
Organizations seeking to adopt resource management
using project schedule data will need to create a resource
entry in the PPM tool for every project team member. In
small organizations, this is easily accomplished, but in large
enterprise organizations, the entire resource pool needs to
be converted from a corporate directory or an organizational
hierarchy. The resource pool also needs to be refreshed and
maintained as project teams turn over. Adding resources in
PPM tools isn’t difficult, although it does require planning
for a small conversion for larger organizations.
4. Do all the project managers
understand how to build a project
schedule using a PPM tool?
Microsoft Project and Clarity support resource
management and maintain a resource pool at the server
level and will shift project end dates based on the re-
source pool’s commitments to other projects, corporate-
level holiday calendars, and region-specific calendars.
Project managers need training to effectively use the
server-based project schedule template, assign resources
from the resource pool, and develop the project schedule.
If the project managers are simply picking dates and
assigning resources to tasks, the end result will be a
constraint-based schedule that will cause frustration
when resources are added, dates shift, and
overallocations occur.
If the project managers understand how to build a dynamic
project schedule by leveraging a calendar-driven resource
pool, it will reduce the number of problems encountered
when integrating project schedules within a PPM tool.
A poorly developed project schedule wrapped within a PPM
tool with all the whiz-bang collaboration features and dash-
board reporting is still a poorly developed project schedule.
5. Is this a new project?
Since PPM scheduling solutions require the project
schedule to be developed with a central resource pool,
new projects are better suited to adopt the PPM solution.
If the project already has a developed project schedule,
and the project has been executing outside of the tool,
you should consider a conversion to the PPM solution.
The project team will need to determine if supporting an
administrative project schedule conversion is worth the
time and effort for in-flight projects. I’ve converted in-flight
projects into existing PPM tools, and it is a manageable
but considerable undertaking. Depending on the size of
the project schedule, the effort to convert resources, task
start and finish dates, task baseline start and finish dates,
and dependencies can be a significant.
Evaluation
If you answered “Yes” to all these questions, then your
project is better prepared to integrate the entire project
schedule with the PPM solution. If you answered “No” to
any of these questions, your project may be better suited
to publishing a milestone-level schedule in the tool. If you
decide to publish a milestone-only level schedule, your or-
ganization will lose accurate visibility to the PPM resource
management features and just-in-time schedule reporting.
However, resource management may not be a priority com-
pared to an accurate inventory of projects in the portfolio.
Integrating a milestone-only schedule will also require
you to monitor milestone dates and update the data in
the PPM tool separately. In large programs, I’ve created
my own milestone-level project schedule that contains
individual milestones from each project in the program. I
monitor these milestone dates by comparing them to the
detailed level plans and update the PPM tool accordingly.
Tradeoffs
Internal projects that use an established pool of resources
and a single integrated plan can benefit from a complete
project schedule level of integration. If you adopt this ap-
proach, you will need to balance the administrative schedul-
ing overhead in addition to the actual delivery of the project.
If your organization isn’t actively prioritizing resource man-
agement, I favor a milestone-only approach. If resource
management is required, there are other techniques to
consider in addition to examining project schedules. No
one ever rewarded me for publishing a detailed project
schedule in a PPM tool, but they did appreciate the suc-
cessful delivery of a project.
The PPM features are enticing to use, although the deci-
sion making is only as good as the data in the system.
Despite the one-click push button demonstrations,
integrating a project schedule with a PPM solution isn’t as
easy as it seems. You need to consider the application of
the tool and its collaborative use within the project before
jumping to a detailed or a milestone-level integration.
151
Build a customized Gantt chart view
in Microsoft Project
The number of views into Microsoft Project’s scheduling core schedule data needed to define, track, and update
data can be overwhelming. The delivered views on the Mi- your project schedule. For the past few years, I’ve been
crosoft Project view bar include the Gantt chart, resource using a custom view called myGantt that provides all
usage, task usage, and resource graph views. When you the data I need to update project progress and track the
combine these views with the entry, cost, tracking, and project schedule (Figure B).
variance tables, it can get confusing.
You can create your own myGantt view by following these
Novice project managers remedy this problem by add- steps.
ing every column of data that they’ll ever need into the
Gantt chart view. The
end result is there are Figure A
too many columns in
one view, and it creates
information overload. It
quickly becomes difficult
to navigate, print, and
manage the project data
(Figure A). (I’ve inher-
ited project schedules
that had more than 20
columns in a single Gantt
chart view.)One solution
is to create a custom
view that provides the

This Gantt Chart view has too many columns.

Figure B

A look at myGantt view

152
Create a set of custom tables and effort-driven tasks, you should include Actual

views based on the delivered Work and Baseline Work fields.

entry and tracking tables 3. Click the OK button.
By creating custom tables and views, you’ll import the
Create a custom myEntry view
same data and still be able to switch back to the delivered
1. Go to View | More Views.
Gantt chart and standard tables. If you don’t create a
separate set of tables and views, any changes you make 2. In the View Definition dialog box, enter myEntry

to the underlying tables will affect the standard views in for the Name, select the myEntry Table, set

Microsoft Project. the Group to No Group, and set the Filter to All
Tasks. Click the OK button. (Figure D)
1. Go to View | Tables | More Tables and select the
Entry table. Create a custom myTracking view
1. Repeat the steps above and use the myTracking
2. Click Copy and rename the table to myEntry
view.
(Figure C).

3. Click the OK button. Create a myGantt

combination view
Create a custom myTracking The combination view splits the Microsoft Project work-
table
space into two panels; this allows you to see the entry
1. Repeat steps 1-3 from the previous section and
and the tracking data all in one view.
use the Tracking table.
1. Go to View | More Views | New.
2. Edit the table to include these fields: Name, Ac-
tual Start, Actual Finish, Baseline Start, Baseline 2. Enter myGantt for the Name and select myEntry
Finish, % Complete, Actual Duration, Remaining for the Top view and myTracking for the Bottom
Duration, Baseline Duration. If you’re tracking Views Displayed (Figure E).
Figure C

This is the myEntry table

153
 1. Click the Show In Menu checkbox.
Primary benefit
2. Click the OK button. The key benefit of this myGantt view is the amount of

Test your view time you’ll save switching between different views and

By clicking the Show In Menu checkbox, you should inserting or hiding different columns. With one combina-

see the myGantt view in your View Bar and in your View tion view, the project manager is able to view the baseline

menu. dates, the actual dates, and the impact of those dates to
the forecasted schedule. Using this single combination
1. Go to Click On View | myGantt. The myGantt
view, you can record the actual duration and the remain-
view from Figure B will be displayed.
ing duration to generate an objective percent complete.

With this view, you can click on one task in the upper The supporting Gantt chart can still be formatted to view

window pane and view all the relevant tracking data in the the critical path or other Gantt chart wizard graph charts.

lower pane. By highlighting multiple tasks, you’ll receive You can also change the upper and lower window panes

all the key information you need to track your schedule. based on the tracking or the resource utilization needs.
Since you created custom objects, you can easily revert
to the original views by clicking the Gantt chart icon
Figure D and removing the split view.

You can change the upper and lower window panes

based on the tracking or the resource utilization
needs. Since you created custom objects, you can
easily revert to the original views by clicking the Gantt
chart icon and removing the split view.

Innovate
Now that you understand how to customize Microsoft
Project, I encourage you to discover new ways to
view project data. If you have developed innovative
views that you’d like to share with the community,
myGantt View Definition dialog box.
please detail them in the discussion.

Figure E

myGantt View Definition dialog box.

154
Build milestone charts faster with
MindView 3 Business software
A well-defined milestone chart is a useful way to com-
municate a project’s progress and to identify upcoming
deliverables. Unfortunately, I detest creating and updating
milestone charts.
The problem is Microsoft Project doesn’t provide a user
friendly milestone chart that users can easily understand.
The Gantt chart is a great tool for project managers, but
for practical status reporting, it can become unwieldy to
manage, as milestones and summary tasks can yield too
many levels. Project managers typically resort to Microsoft
Excel or Microsoft PowerPoint to develop the appropriate
milestone chart for status reporting (Figure A).
Using desktop office software requires manual changes
Figure A
Program work stream view.
Figure B
Gantt chart view of a sample project schedule.
every time a milestone is completed or a baseline milestone
date changes — there is no clean integration with the proj-
ect schedule and the reporting mechanism. Fortunately, I’ve
found a tool that makes this administration task a breeze.
Using MindView 3 Business
MatchWare’s MindView 3 Business simplifies milestone
chart reporting. The tool’s mind mapping and project
management integration with MindView 3 Business is
excellent. It also provides multiple views of project data,
including a mind map view, a Gantt chart view, an outline
view, and (my personal favorite) a timeline view. The soft-
ware is an asset to project managers implementing scope
definition, activity definition, schedule development, and
on-going status reporting.
I’ve been using the software for
several months and generating
a milestone level status report
takes less than a minute by
following the simple steps I
outline below.
Import MS-Project Schedule into
MatchWare MindView 3 Business.
Open MindView and select Import
| Microsoft Project. The software will
import your project schedule and
build a Gantt chart view (Figure B).
Filter on Milestones
MindView 3 Business has a power-
ful filtering feature that hides project
data based on your filtered criteria.
A unique feature in MindView 3
Business is the filtered tasks remain
filtered in the Gantt chart view, the
155
timeline view, the outline view, and the traditional mile- support multiple formatting options with a click of a but-
stone view. This filtering is useful in a variety of project ton. You’ll be pleased to find changing the format is much
management applications, including activity definition and faster than wasting time moving lines, diamonds, and
status tracking. formatting the objects in a Microsoft SharePoint file.

For this example, I only want to view the milestone data, Click the Design tab and select one of the time-
so follow these steps: line layouts (Figure E).

Select Filter | New. To select the type of project data you want to
When the Filter dialog box appears (Figure C), click
display on the milestone chart, select View |
Add Level and select Duration Equal To 0 day.
Show Branch Data (Figure F)
Click the OK button.
The Gantt chart view will now only display the milestone Select Start/End date and select either Priority,

level tasks. Completion, or Resources.

In the View ribbon bar, click on the Timeline view The final result (Figure G) is ready to export into an image
(Figure D). file to be embedded in a status report, a presentation, or
an email.
The Design view provides a variety of timeline layouts that

Figure C Figure D

Timeline view

Filter dialog box

Figure E

Design and timeline layout

156
Try this timesaver for yourself
Using the Microsoft Office tools, I can easily spend one or
two hours creating the chart and spend even more time
tweaking each milestone so it aligns with the graphical
timeline. The MindView 3 Business method takes under
60 seconds and leverages the existing project data that I
keep up to date in my project schedule.
just glad I found a tool that leverages the project artifacts
I use on a daily basis. Until the project management gurus
create an “Easy Button” for project delivery, I’ll continue
to share the best tools for practical project management.
If you’re interested in taking MatchWare’s MindView 3
Business for a test drive, you can download a free trial
from the company’s site.

As project managers, we accept the administrative bur-

den as part of the job, but we should always be looking
for faster development tools to make our job easier. I’m

Figure F

Show Branch Data

Figure G

Milestone view in under 60 seconds

157
How to use project data to develop
a better estimation matrix
During lessons learned sessions, a common practice is to
highlight what went well and identify areas for improve-
ment on a project. Agile enthusiasts acknowledge project
teams should conduct retrospectives (a.k.a. lessons
learned sessions) after every release and iteration. In
waterfall projects, this activity usually occurs at the end
of the project. Regardless of your preferred methodology, I
recommend comparing actual duration and actual effort to
the baselined effort as part of a lessons learned session.
low, medium, or high. Low estimates were assigned 8
hours of effort; medium estimates were assigned 16 to 24
hours of effort; and high estimates were assigned 32 to
80 hours of effort. The range was tweaked based on the
information available. The key benefit was it provided a
starting point for estimation based on basic information.
Over the past few years, I started collecting metrics
against the Microsoft Project schedule so I could develop
a better estimate matrix based on actual project data.

Effort estimation
Project teams often spend time at the end of a project
documenting lessons learned, although few measure their
actual performance and record it for future estimation.
During effort estimation, project teams conduct either a
bottom-up or a top-down estimate. Bottom-up estimates
require a significant investment in time to define scope
and build an accurate estimate. Top-down approaches use
Figure A depicts a custom table that I used to track and
categorize the actual project data for future comparison.
In this table, I added custom fields to categorize the deliv-
erables, assign a complexity rating, and include a flag to
include in my estimation analysis.
Figure B includes a close-up view of the interface analysis.
In this section, I can quickly see where I underestimated

analogous estimates and rely on expert opinion to estimate the code phases of specific interfaces. Interface 1 had

duration at a high level. If you start collecting actual perfor- a baseline duration of 2 days, and it took 6 days to

mance data and compare actual results against baseline complete the work. Since the data is recorded in days

estimates, you can achieve an analogous estimation tool or hours, I can refine my estimates using both units. By

that is based on bottom-up data from past projects. examining the actual task data, I can start building better
estimation metrics. It helps to understand the root cause
Estimation Figure A
matrix
In my system imple-
mentations, a common
practice involved de-
veloping an estimation
matrix that categorized
reports, interfaces,
conversion, enhance-
ments, and forms (or
screens) and assigning
a complexity level of MyEstimation table

158
of why a medium interface moved from 2 days to 6 days.
Based on the root cause, I may adjust the matrix to ac-
commodate better estimation.
After I export the data to Excel, I can update my matrix in
Figure C.
Summary
For a lessons learned session, I am not suggesting you
track every task, although I do recommend tracking
against the major activities required to produce specific IT
deliverables. For your next project, you’ll need to conduct
similar effort estimation activities. By comparing estimates
against actuals for specific deliverables, you continue to
build a better estimation matrix.
In my next column, I’ll show how to track and export this
data using a variety of views and maps in Microsoft Project.
How do you track your estimates and build more objec-
tive estimation tools? Let me know in the forums.

Figure B

Interface actual and estimate comparison

Figure C

Estimation matrix

159
Export project data for future effort estimation
In my previous column, I explained how to use project 1.
data to develop a better estimation matrix. The key bene-
fit of tracking the actual project effort and comparing it to
2.
your original project estimates is that you can refine your
estimation matrix for future analogous top-down estima- 3.
tion. Even Agile enthusiasts would value this approach for
their next round of Planning Poker, as the effort estimation
is based on prior experience for similar types of work.
Open the Sample Schedule with myEstimates.
mpp file.
Select Tools | Organizer.
Click the Tables tab, click myEstimateCompari-
son table, and click the Copy button. This will
copy this custom table to your PC, where you
can use it for other project schedules.

I provided a very simple estimation matrix based on
the common RICEF deliverables of reports, interfaces,
conversion, enhancements, forms, and screens in Figure
A. You can tweak this matrix even further by analyzing the
project data from your Microsoft Project schedule. If you
follow the eight steps outlined below, you’ll be crunching
numbers in a few minutes.
Step 1: Configure your
estimation table
I could write several articles on how to effectively custom-
ize Microsoft Project with your own tables, view, and maps;
however, it’s easier if you download this sample Microsoft
Project file (Sample Schedule with myEstimates.mpp) and
copy the relevant objects into your Global.mpt file.
After you download the sample schedule, follow these
steps:
4. Click the Fields table and follow the same steps
to copy the Estimation Category, Task Com-
plexity, Task Category, and Include Estimation
fields to the Global.mpt file. These fields map to
Text28, Text29, Text30, and Flag20, respectively.
If your project schedule currently uses these
fields for other purposes, you’ll need to custom-
ize the fields using the Tools | Customize feature
in Microsoft Project.
5. Click the Maps tab and copy the myEstimates
map into the Global.mpt file.
Step 2: Assign Task Category
to tasks
Once the project fields, table, and export map are copied
to your local PC, open your project schedule. Click the
Gantt Chart view and switch to the myEstimateComparison

Figure A

160
table. The custom table was created to replicate key Mi- table similar to Figure B with blank values.
crosoft Project fields without modifying the core Microsoft
The default Task Categories field includes these values:
Project table structure.
Report, Interface, Conversion, Enhancements, Form,
Follow these steps to switch tables: and Screen. If you want to modify these values, simply
click Tools | Customize | Fields and modify the Custom
1. Select View | Table.
Attributes (Figure C).
2. Select the myEstimateComparison table.
Find the key task you want to track in your project sched-
If the table doesn’t appear in the menu items, click the ule and assign a task category from the drop-down menu.
More Tables button and select the table. You should see a
Step 3: Assign Estimation Category
The Estimation Cat-
Figure B
egory field includes
Requirements, Test,
Code, and Deploy valid
values; you can modify
these values to accom-
modate your systems’
development lifecycle.
Figure C The Estimation Category field is used
to identify the time spent in specific
phases for key deliverables.

Step 4: Assign Task

Complexity
The Task Complexity field consists of
low, medium, and high values. Depend-
ing on your estimation approach, you
may want to add values for smaller or
larger work.

Step 5: Set the Include

Estimation flag
The Include Estimation field is used as
a filter so you can view all the key tasks
or deliverables you want to track in
Microsoft Project or in a spreadsheet.
You need to set the Include Estimation
flag to Yes or No.

161
Step 6: Repeat for each of the RICEF Step 8: Export to Excel using the
deliverables you want to track for myEstimates map
future estimation. Open the exported data in Excel, and you can filter by
Step 7: Export to Excel using the the estimation columns to further analyze durations. The
myEstimates map translation from the raw Microsoft Project data to your es-
Exporting data from Microsoft Project to Excel or a timation matrix only takes a little bit of data manipulation.
different format is easy to do. Since you already have Programmers will be tempted to write macros to update
the myEstimates map, you can save the file as an Excel the estimation spreadsheets, although I recommend
export with just a few clicks. project managers inspect the duration and effort data and
make decisions on where to adjust their estimation matrix.
1. Select File | Save As.

2. Select Excel Work Book Figure D

(*.xls), enter a filename,
and click Save.

3. When the Export wizard

dialogue box appears,
click Next.

4. Click Next.

5. Select the Use Existing

Map radio button.

6. Click the myEstimates

Map (Figure D).

7. Click Finish.

162
View the critical path in Microsoft Project
In my previous column, I explained the purpose of the To start the Gantt Chart Wizard, follow these steps:
critical path and why project managers need to be
1. Go to Select Format | Gantt Chart Wizard. You
concerned about monitoring the project’s critical path
can also right-click the Gantt Chart and select
during schedule execution. This tutorial has step-by-step
the Gantt Chart Wizard from the pop-up menu.
instructions on how to view the critical path in Microsoft
2. When the Gantt Chart Wizard starts, click Next.
Project and interpret the data.
3. Select the Critical Path radio button (Figure B)
I use the same Microsoft Project file from last week’s col-
and click Next.
umn. If you need to download the file, you can download
it from my article on Network Sensitivity and the Critical 4. Choose the task information options and click

Path. Let’s get started. Next. (I prefer to keep the default Resources and
Dates options.)
To see the Gantt Chart View, follow these steps:
5. Keep the default links between the dependent
1. Open your project schedule in Microsoft Project. tasks option and click Next.

2. Go to View | Gantt Chart View.

6. Click the Format It button and exit the wizard.
3. Go to View | Table | Entry. (See Figure A)
Figure A

Sample project schedule

Figure B

Gantt Chart Wizard dialog box

Figure C

Critical path Gantt Chart

163
Figure C displays the formatted Gantt chart. 1. Confirm the Standard toolbar is displayed. It
should be there by default, but if it isn’t, you can
With the formatted Gantt Chart, you can easily see the
go to View | Toolbars | Standard.
critical path and the project dependencies. If any of
these tasks are delayed, then the project’s end date will 2. Click the Group By drop-down box (Figure E) and
be impacted. Task 4 is not on the critical path, so it has select Critical from the list of Values.
several days of float in the schedule before it impacts the
The critical and non-critical tasks will be conveniently
project schedule.
grouped for further analysis and reporting (Figure E).
If you want to get a list of just the critical path tasks (Fig-
The Schedule table is useful when you want to under-
ure D), you can use the Group By option in the Microsoft
stand the slack in the schedule. With the critical tasks
Project toolbar. I often use this view to determine which
grouped, you can quickly view the available slack in the
tasks and resources are on the critical path. This extra
non-critical tasks.
level of detail helps me understand what needs to be ac-
To view the slack in the project schedule, follow these steps:
complished and who is responsible for the task.
1. Go to View | Table | Schedule.
To view the critical path tasks, follow these steps:

Figure D

Critical path tasks

Figure E

Group By option

Figure F

Schedule table

164
 2. The Schedule table will be grouped by Critical Microsoft Project can also create the standard forward
and Non-Critical tasks (Figure F). pass and backward pass views with early starts and late
finish data that you likely calculated if you prepared for
The Network Diagram is another view that is helpful in
your PMP exam. I’ll cover this more advanced topic in a
understanding the critical path. A Network Diagram is the
future tutorial.
classic Activity on Node schedule dependency diagram
you may have seen in project management courses or in If you’d like to see a video tutorial of these steps in action,
the Project Management Body of Knowledge. please view my How to View the Critical Path in Microsoft
Project video.
To view the Network Diagram, go to View | Network
Diagram. You can also click the Network Diagram in your
View Bar, which is located on the left hand side of the
screen. Figure G displays the Network Diagram.

The tasks highlighted in red display the critical path, while

the blue tasks are not on the critical path.

Figure G

Network Diagram

165
Using a fixed duration task type
in Microsoft Project
A colleague and I were discussing how Microsoft Project Using the Duration X Units = Work formula, the project
calculates duration, work, and resource utilization. My manager will enter duration and work into Microsoft
colleague was managing an outsourced project under a Project and let the tool calculate resources.
time and materials contract and wanted to schedule a
To create a four-hour task using a three day fixed dura-
four-hour task over three days. He had a few challenges
tion, follow these steps:
trying to schedule the task in Microsoft Project until we
discussed the importance of task types and the Duration 1. Insert the Type and Work fields into the Gantt
X Units = Work equation. Chart view.

Microsoft Project schedules tasks based on three vari- 2. Enter the task name.

ables: duration, units (or resources), and work. You get 3. Change the Type field to Fixed Duration.
to choose two of these variables, and Microsoft Project
4. Enter 3 days in the Duration column.
calculates the third. Project managers run into a schedul-
5. Enter 4 hrs in the Work column.
ing circle when they try to hold all three of these variables
fixed. Just like the scope, cost, and time project triangle, 6. Assign a resource.

if you change one variable, the others adjust as well. 7. Microsoft Project will calculate the 17% utilization.

In my colleague’s scenario, the project manager has three Figure A depicts Task A using a three-day duration, four

days to complete four hours of work. Since the project is hours of work, and 17% resource utilization.

outsourced to a vendor, and the project manager doesn’t

Figure A: three-day duration with four hours of work
have direct control of the resource, a fixed duration task
type is recommended. The project manager doesn’t care In the Task B example, a Fixed Work task could be

when the work gets

Figure A
done, as long as it’s
in the three day esti-
mate. By setting the
task to use a fixed
duration task type,
Three-day duration with four hours of work
the number of hours
and resources can
fluctuate, and the three day duration will remain constant. entered with a resource assigned 100%, and the resulting
duration would be 0.5 days. Since the requirement is to
In actual practice using a time and materials contract,
complete the task within three days, the fixed duration
the project manager would care about the number of
task is recommended.
hours spent from a budget perspective. From a schedule
For internal projects with internal resource costs, I prefer
perspective, the project manager is still expecting a three
to build fixed duration tasks using 100% allocated re-
day fixed duration for the task.
sources and let Microsoft Project calculate the work. For

166
external projects that use different contract types, the mix
of task types will depend upon the work and the level of
tracking required in your project schedule.

To learn more about the different task types, read my

Microsoft Project tutorial, Use Fixed Duration, Fixed Work
and Fixed Unit Type Fields.

167
Confirm your Microsoft Project Schedule
is ready for EVM
Over the past nine years, I’ve been studying earned value assigned to the task. By ensuring resources are
management (EVM) and its application to IT projects. assigned to the lowest level in each work pack-
According to PMI’s Project Management Body of Knowl- age, the cost will roll up appropriately.
edge, EVM is an “objective method to measure project
4. Confirm no resources are over allocated
performance in terms of scope, time and cost.” If you’re
Despite our desire to give 110%, a realistic
unfamiliar with EVM, read my overview before proceeding
schedule has resources only allocated 100% of
with EVM metrics in Microsoft Project.
the time.
EVM metrics are easy to calculate, as it only requires
5. Confirm the total costs for each work
simple math. According to industry research, there are 40
package match contractual agreements
critical success factors to successfully implement EVM
Microsoft Project builds a time-phased budget
in an organization. One of those critical success factors
for each task and allocates planned work and
is the project management team can develop a project
costs according to the project calendar. If your
schedule and track against a project baseline. A properly
project contracted for $100,000, the total cost in
developed Microsoft Project Schedule is critical in calculat-
the WBS should reflect $100,000.
ing EVM metrics when using Microsoft Project. A poorly
defined Project Schedule will result in poor EVM metrics. 6. Confirm the project has a project baseline
The project baseline establishes the time-phased
The following is a quick checklist to confirm your Micro-
budget for the project and allows PV to be calcu-
soft Project Schedule is ready for EVM.
lated. If you don’t baseline the project, you can’t
1. Confirm the Work Breakdown Structure (WBS) measure what you’re trying to manage.
has been correctly defined with the appropri-
7. Confirm the project management staff under-
ate work packages
stands the procedures to record actual start,
Meaningful earned value metrics are only as rel-
finish, duration, and costs data for the project
evant as the tasks they represent. If you’ve built a
schedule
poorly defined WBS, earned value can’t help you.
As the project progresses, it is important that
2. Confirm the work resources have the appropri- anyone updating the project schedule follows a
ate hourly rates in the Resource Sheet view consistent procedure to record start dates and
Microsoft Project determines the work package’s actual costs. If teams use inconsistent practices,
budget based on each assigned work resource’s your earned value results may be off.
hourly rate. If you don’t have a defined cost for
8. Confirm the project status date is set in Micro-
each resource, your budget will be zero.
soft Project before examining EVM metrics
3. Confirm all tasks have resources assigned at If you don’t specify the project status date,
the lowest level in the WBS Microsoft Project will assume the current date
A task establishes its baseline budget and is the date used for calculating the earned value
planned value (PV) based on the resource costs metrics. Since status reporting usually follows

168
 the prior week, you’ll want to set the project
status date each week to calculate accurate
metrics.

There are 39 other critical success factors that organiza-

tions should consider before implementing EVM across an
organization.

For more information about how to use earned value with

Microsoft Project, read my tutorial, How to Calculate EVA
in Microsoft Project.

Copyright ©2009 CNET Networks, Inc., a CBS Company. All rights reserved. TechRepublic is a registered
169 Street San Francisco, CA 94105 U.S.A.
trademark of CNET Networks, Inc. Cnet Networks, Inc. 235 Second