When
I read job postings for IT project managers, there is a heavy focus on being
able to deliver on schedule and on budget. In addition, I sometimes hear rather
lively discussions about the role of the project manager: are they/should they be
accountable for anything at all beyond schedule and budget? I’ve also observed
from my own project management experience that the first questions from the
sponsor and from the steering committee are invariably “how much will it cost”
and “when will it be done”? Again, the focus is on schedule and budget.
Why
are schedule and budget the big focus of project managers and the executives
for whom they deliver projects? Is that where all the big risks are?
The big risks
In
my opinion, schedule and budget overruns are not the big risks themselves. They
are the outcome of other risks that have materialized into issues. So, what are
the biggest project risks that drive schedule and budget problems?
In
a previous article Identifying and Managing Project Risk by Tom Kendrick (book
summary), I summarized Tom Kendrick’s book, in which he outlines his findings
from examining hundreds of technical projects. In the book, all the risks that
occurred were translated to a timeline impact so they could be compared. I
think it’s a fair assumption that when the timeline is extended, the cost also
grows. So, what are the risks that have the greatest impact? From Kendrick’s
book, two risk areas with the greatest impact are: (a) non-mandatory scope
changes; and (b) legitimate, but not anticipated, requirements gaps.
In
other words, the big risks are related to scope and requirements. There are
plenty of other risks, but let’s start with these two. When these risk events
occur, there is an impact on the schedule and budget.
Managing scope and requirements
There
are several ways to focus on scope and requirements.
First,
these need to be defined as clearly as possible at the outset. Too often there is a rush to get the project
started, and it begins with inadequate descriptions of scope and requirements.
This rush to delivery and related skimping on scope and requirements can lead
to disastrously large impacts on schedule and budget.
Sometimes
there is a good reason to have uncertainty at the start of the project. In that case, identify the lack of clarity as
a project risk. Then, make sure that everyone on the project and on the
steering committee knows about that risk. Also be sure to include a
re-assessment point in the schedule and funds in the budget to address the cost
of potential changes.
Next,
focus on requirements and scope during the project. At the outset, meet with the project team(s)
to review these in detail and address any questions. It is crucial that the
team knows what is to be delivered.
Make
sure there is a change control process and that it is followed.
Review
and follow up on the project issues frequently. Issues are often the result of disagreement
regarding what is in scope or what is needed. Too often, issues are logged in a
database and neglected.
During
the project there should be checkpoints to verify that the project team is on
track. Hold walkthrough meetings with team members, and also with stakeholders
outside the team. While often seen as time consuming, these walkthroughs are critical
tools to ensuring the delivered product supports the requirements and scope of
work.
An
effective way to determine during the project if there are issues with scope
and requirements is to ask team members informal questions about what they are
working on, whether they are clear enough on what they need to do, and what
problems they are having. The project
manager needs to make herself available when there are questions from the team
regarding scope and requirements, and not put them off while heads-down adding
up budget hours or updating Gantt charts.
Testing
is another method of ensuring that the delivered product meets requirements and
scope. Evaluate test plans to determine if they engage the right people and
cover the right tests to identify gaps in scope and requirements. Ideally, gaps
should be identified before testing, but even if found during testing, at least
they are dealt with before go-live.
Conclusion
When
hiring and evaluating project managers, the heavy focus on schedule and budget
overlooks the relationship between schedule and budget, and project risks. It’s usually the project risk events occurring
that cause the budget and schedule problems.
Managing the schedule and budget is really about managing the project
risks. In this article, I picked two top risks and discussed common techniques
to manage them.
I’ll
leave you with a couple of thoughts. First, I think the question about whether the project manager is responsible for anything besides schedule
and budget has a definitive answer. Project Management Institute says yes, as
the knowledge areas cover a lot more than schedule and budget. Quite apart from PMI’s body of knowledge, the
answer has to be yes, because if you aren’t managing the project risks, it
isn’t possible to manage the schedule and budget.
My
second parting thought: If the project comes in on time and on budget, but does
not deliver the expected scope or meet requirements, what was really achieved?
Copyright
2015 Debbie Gallagher
