Project Cost Management

 Cost Management |  By Joseph Phillips |  Read time 11 minutes

I'm not a huge fan of country music, but Lyle Lovett is one of my favourites. How can you not
like Lyle Lovett? After all, he married Julia Roberts. (Ah, Julia Roberts, if you've read my
articles before, you know how much I admire that smiling beauty. Sure, she snubbed Keifer,
dumped Lyle, had a set of twins, and refuses to return my phone calls. Still, she is Julia
Roberts.) Anyway, the point I'm trying to make is that I like Lyle Lovett's music: rhythm and
blues, big band, good ol' country. In one of Lovett's songs, he croons, Would you like a
kiss? She said, Thank you, no. I'll take some M-O-N-E-Y. Project managers are like the girl in
Lovett's song: Management asks, Would you like more time? We respond, Thank you, no. I'll
take some M-O-N-E-Y. Customers offer, Would you like to reduce the scope? We
answer, Thank you, no. I'll take some M-O-N-E-Y.
Sponsors demand a speedier schedule. We respond, Thank you, no. I'll take some M-O-N-E-
Y. From IT to construction, most projects have to purchase materials: routers and cables,
shingles and cement, and so on. We almost always must buy some things to complete the
project work. Think back to your last project; didn't you have to buy something? A piece of
software. A book. A large double-cheese and sausage pizza for your team. Someone, you or
the organisation you work for, had to cough up the cash to buy that stuff.
Regardless of scope or schedule, projects need funds to complete the work. Technically, even
projects that use only labour have funds attached to them; someone, somewhere is paying for
that labour. What happens if you don't have the correct amount of funds to complete the
project scope? Your project is doomed.

Got Your Money on Your Mind?

How do we know what a project will cost? We really don't, until the project is complete. I
sound more like a car mechanic than a project manager, but the truth is, and this may sting
just a little, we can't know the final project cost until the project is complete because we can't
accurately predict the future.
What we can do is create an estimate. An estimate is more than pulling a random number out
of the air, adding 20% for good measure, and then saying, That'll work. A real estimate
evolves as project details become available. This is progressive elaboration. Project estimates
start out broad, and as the project deliverables come into focus we're able to more accurately
define our estimates.
Each estimate should provide an acceptable range of variance, the conditions of the estimates,
and any assumptions made by the estimate provider. For example, an estimate to build a new
warehouse may state that the warehouse will cost $350,000, +/- 10%, is valid for 30 days, and
assumes that the warehouse will be built in the month of June.
Notice the range of variance, the assumptions, and the stated work? A good estimate clearly
defines what the project will accomplish, the assumptions made, how long the estimate is
valid, and how much the project will cost based on current information. A good estimate
presents to the stakeholder everything relevant to the proposed work, without holding back
any secrets. If there's a disagreement in price, assumptions, or range variance, it's better to
discuss this issue now rather than four months into the project execution.
There are three major estimate types that project managers should rely on:
The Ballpark Estimate is also known as the Rough Order of Magnitude (ROM). A ROM
estimate is based on high-level objectives, provides a bird's-eye view of the project
deliverables, and has lots of wiggle room. Most ROM estimates, depending on the industry,
have a range of variance from -25% all the way to +75%. Like I said, lots of wiggle room.
The project manager shouldn't invest too much time in creating these initial estimates, just as
the customer shouldn't place too much confidence in the accuracy of the ROM estimate.
Unfortunately for both parties, there's a consistent breakdown in expectations when it comes
to ROM estimates. Typically the project manager blindly throws out the ROM estimate like a
bride tossing her bouquet, and the customer clings to the ROM bouquet like the maid of
honour at the same wedding. ROM estimates, regardless of your role in the project, are simply
for eyeballing the project's initial perceived costs.
The Budget Estimate (or top-down estimate) is a bit more accurate. Formulated fairly early in
the project's planning stage, the budget estimate is most often based on analogous estimating,
taking budget lessons learned from a similar project and applying them to the current project.
Do a little maths magic and we've got ourselves a budget estimate. Abra-cadaver!
With the budget estimate, we start at the top and work our way down into the project details.
Like the ROM, this estimate should include conditions, a range of variance, and any
assumptions that went into your calculations. A budget estimate is quick, but not very
accurate. The range of variance on the budget estimate is from -10 percent to +25 percent.
The Definitive Estimate (or bottom-up estimate) is the most accurate of the estimate types, but
takes the most time to create. The definitive estimate requires a Work Breakdown Structure
(WBS). A WBS is not a list of activities. (I know, everyone at your office says it is, but they're
all wrong.) A WBS is a deliverables-oriented decomposition of the project scope. That's
decomposition of the deliverables that your project will create for the customer, nouns, not
verbs.
For example, suppose you need to create a network from scratch in your organisation's
headquarters. Your WBS will stem from the project name HQ Network. Below HQ Network,
you create a family tree of major deliverables: LAN, WAN, server room, workstations, and so
on. Then you decompose these major deliverables into smaller deliverables.
Your WBS should use a code of accounts to number each deliverable in the WBS. For
example, assume that the HQ Network is project number 427. The WAN section of this
project might be 427.1, and the elements under the WAN deliverables would then be 427.1.1,
427.1.2, and so on. This code of accounts clarifies for all participants the deliverable that is
being referenced, providing an accurate record for any element the project manager promises
as part of the project completion. You don't have to use a code of accounts, but it's easy
enough to implement, and can save time downstream.
You need a WBS in order to create the definitive estimate because you and/or your experts
will account for the cost of each deliverable. In some organisations, that cost can include more
than just the materials, it may take into account labour, consultants, team development, and so
on. The point is that each deliverable in the WBS can have time and costs associated with it.
Depending on the size of your project, you may want or need to create a WBS dictionary to
take advantage of the code of accounts for each of the WBS elements: defining each element,
the party responsible for the element, time and costs associated with each component, and
other notes or relevant facts.
A WBS dictionary, coupled with the code of accounts, helps to prevent or resolve
miscommunications, provide accurate references, and organise the project deliverables. Tied
to the WBS dictionary are time, costs, and relevant info on each deliverable. Now you and
Larry from Accounting can be best friends forever. You can move to any deliverable in the
project and give an accurate estimate of what each thing will cost to implement.
A definitive estimate takes lots of time to create, but it's the most accurate estimate you can
provide. You may know this as a bottom-up estimate because you start from zero (the bottom)
and account for each freakin' thing the project will purchase, create, or deliver. The range of
variance on a definitive estimate is relatively low: -5% to +10%. This makes sense because
it's much easier to predict how much something will cost when you can see everything the
project will create. How many projects have you been involved in where you can see
everything the project will create from the word go? Probably not too many, or only projects
that you've completed repeatedly and therefore know exactly what's expected. For example,
an IT integrator may have a project template that defines all of the work to implement a
prepackaged solution in any environment.
While definitive estimates are ideal for accuracy, they're not easy to create because so much
effort has to go into the project before the project manager can create the definitive estimate.
This requires education not just for you as project manager, but for your stakeholders, who
need to understand that the only way a precise estimate can be created is to invest time in the
project itself, by creating the WBS.
With any type of estimate, the project manager must provide the range of variance and an
explanation of how the estimate was created. Without these explanations, the customer is led
to believe that the price you've quoted, the price you've "promised," is the final price that the
customer will see. And should the price tag change, there'll be hell to pay.
Got Your Mind on Your Money?
As the project moves toward completion, there will likely be a need to revise the project's
price. If the project started with a ROM estimate, the original estimate could be wildly wrong.
The customer who reads the ROM estimate should know that the final cost is likely to be
much different from that estimate. No doubt the customer will be anxious to hear your more
accurate definitive estimate.
Of course, from ROM to definitive, estimates can be just plain wrong. It's not fun to have to
approach your sponsor, stakeholders, or customer with hat in hand and beg, plead, scrounge
for more cash because your project estimate was way, way off. Poor planning is the major
cause of poor estimates. Rushed estimates, bloated estimates, or estimates that are "low-
balled" just to get the project moving are bound for budget reviews, unpleasant conversations,
and project reassessments.
Sometimes, thankfully, it's not the project manager's fault when the estimate must change: The
cost of materials has changed, the anticipated time to complete the project work was wrong,
or the bases for decisions were faulty. In these instances, the project manager still has to
communicate the variances, which isn't fun, but it's easier than taking the blame when that
blame is all yours.
Poor estimates can also be the fault of the customer, stakeholders, or even the project sponsor.
When the stakeholder is responsible, the increase in cost is usually tied to a change request.
Contrary to public opinion, change requests are not good things. Ideally, when the customer
and the project sponsor sign off on the scope statement, no changes should ever be made to
that scope. Of course, errors and omissions, technological enhancements, and value-added
changes all affect the scope's resistance to change.
If the customer demands new deliverables in the project scope, however, a price tag is usually
associated with those demands. The monies needed to implement the change have to come
from somewhere, and not your wallet. Even changes that replace current scope components
may have a price; time and monies may already have been invested in these deliverables. In
my opinion, change after the scope statement is a bad, bad thing.
We'll talk more about change management in a future article. For now, know this: When the
project scope changes, the budget usually has to change as well. Changes generally cost
something, and that means a budget increase.
IT and Project Cost Control
Do you ever feel like you're playing on the budget dartboard? The vendor's cost has increased.
The historical information is flawed. Time estimates are incorrect. The project team is spread
too thin. The bribe was lower than expected. Excuses, excuses, right?
IT suffers from a universal law: the first-time, first-use penalty. The concept of the first-time,
first-use penalty is that it's next to impossible to accurately estimate the cost of something that
has never been attempted. IT is so unique, so multifaceted, and has so many fronts that the
constant movement of its variables creates a love-hate relationship for any organisation trying
to create an IT cost estimate.
Consider any IT project, from replacing hardware to rolling out an entire new system, and I
bet you've got a first-time, first-use scenario in there somewhere. Sure, that type of work may
have been done before, but not in this project's specific environment. You've got different
types of hardware, firmware, software, and don't forget users, banging up against your
solutions. All of these factors are often ignored, dismissed, or assumed to be non-issues.
Mistake! When it comes to cost and things that can affect cost, the project manager must
consider the risk and ramifications of the first-time, first-use penalty. This universal law can
spell disaster for any IT project. The longer a project manager goes without at least nodding in
the direction of the first-time, first-use penalty, the bigger the pending fall.
Cost and the Project Manager
Project managers are in a tough spot: They're the liaison between the customer and the project
team that will complete the customer's project. In most organisations, it's generally easier to
get more time than money, and there's usually more concern about how much than how long.
Project managers and their stakeholders need to go into any project with a common goal:
Identify an affordable scope and a plan of how to achieve it. Too often, and maybe because of
the subject matter itself, cost is ignored in project planning. For projects to be successful,
someone has to foot the bill, and until the estimate is requested or provided, it's not a mystery,
just a constant dread.
Cost management really is like a Lyle Lovett song: It can be painfully sad, honest, and
focused on M-O-N-E-Y, without ever really saying that word.
Joseph Phillips is the author of five books on project management and is a PMI Project
Management Professional, a CompTIA certified Project Professional, and a Certified
Technical Trainer. For more information about project management training, please
visit Instructing.com

Writing a Funding Proposal

If you are already familiar with the ubiquitous project brief and would like to try something
new, here's an idea. Why not try writing a funding proposal.
We can use a funding proposal to request funds by providing a compelling case for the
proposed project. The main difference is the focus on the goals and objectives of the project,
feeding into a set of measures for the evaluation of project success. The proposal features a
full breakdown of project resources and costs in greater detail than usually found in a project
brief.
The focus on objectives and measures adds some rigour, making the project manager think
carefully about specific activities. These must be measurable so project success can be gauged
by whether these objectives are met.
In the required resources section, the document covers personnel, facilities, equipment,
suppliers and budget. Funding covers much more than just people, and it is crucial to include
office space, furniture, computer equipment, consumables, third-party supplier costs, etc.
It's essential to describe precisely how you will decide whether your project has been
successful. The evaluation plan tells how you will show that the investment was a good one at
the end of the project.
Finally, include a detailed project plan, which shows your timeline and detailed task level
information.
The typical contents of a funding proposal might look something like this:
Project Outline
Background Information
2.1. Opportunity Statement
2.2. Vision
2.3. Positioning
Project Details
3.1. Goals & Objectives
3.2. Customers
3.3. Methods
3.4. Staff / Administration
Available Resources
Required Resources
5.1. Personnel
5.2. Facilities
5.3. Equipment
5.4. Suppliers
5.5. Budget
Evaluation Plan
6.1. Formative Evaluation
6.2. Summative Evaluation
Appendix 1: Project Plan
Is Your Project Proposal READY?
 Project Documentation |  By Duncan Haughey |  Read time 5 minutes

The mnemonic READY is useful when creating a project proposal. It provides a memory aid
to help make sure your proposal is:
Relevant
Engaging
Authoritative
Directional
Yield Optimised
What follows is how to write a compelling and well thought out proposal that will be difficult
to ignore.
1. Relevant
1.1. Fulfils a Need
Does your proposal address a genuine business need? If not, this is your first problem. Why
should the business invest time, effort and money in your project?
1.2. Focussed
Is your proposal concentrated on how you will address the business need? Make sure it is
clear to anyone reading it what it is you are proposing to do.
1.3. Timely
Is the time right for this project? Will your proposal be well received now, or is there a better
time to present it in the future? If there is a better time, consider holding off.
1.4. Meaningful
Make sure the project is important to the business and not just somebody's 'pet' project.
2. Engaging
2.1. A Compelling Value Proposition
Have you created a strong value proposition? Have you explained how investing in this
project will, for example, increase revenues, reduce costs or produce a faster time to market?
2.2. Easy to Understand
Is your proposal written in a way the reader will immediately understand your project's aims,
objectives and benefits? Write in plain English avoiding jargon and use of highly technical
language.
2.3. Answers Questions
Does your proposal answer all possible questions? You can test this by asking a colleague or
friend to read your draft proposal and see if they have questions once they've read it.
2.4. A Passionate Attitude
Have you communicated your passion for the project in the proposal? Consider whether you
have written your proposal in active language. Avoid passive voice and use active voice in
your writing. Passive voice is usually wordy, so you can improve your writing by using active
sentences.
2.5. A Rational Justification
Do you have a compelling argument for your project? Prepare an elevator speech to justify
your proposal. This speech will help anyone interested understand why you believe your
project should go ahead.
3. Authoritative
3.1. Accurate and Concrete
Are all the facts and figures in your proposal correct? Make sure you have checked figures
related to increased revenues, reduced costs or faster time to market to ensure they are
accurate. Avoid guesses or statements that are easy to challenge.
3.2. Minimises Risk
Create a section in your proposal around risk. Show you know there are risks and state clearly
how you intend to deal with them.
3.3. Give Assurances
Have you set the readers mind at ease by assuring them the project can deliver the expected
benefits? Give assurances that you have considered the risks, issues and the wider impact of
the project on the organisation.
3.4. Avoids Fluff
Do not include woolly or vague statements you cannot back up with hard facts and figures.
Avoid irrelevant filler material used just to bulk out your proposal.
3.5. Enough Depth
Provide enough information for the reader to understand what you are proposing. Find a
balance between a proposal that is too thin and superficial and one that is too detailed and
hard to read. Provide enough detail, but not too much.
3.6. Sets Expectations
Is it clear what will happen if the project is approved? Can the proposal be misinterpreted,
leading to disappointment or arguments over whether the result was a success?
3.7. Builds Confidence and Trust
Does your proposal show you (the writer) as a trustworthy and confident person? Avoid
indecisiveness and give the impression you know how the project will deliver any particular
element.
4. Directional
4.1. What Will You Do?
Say what you will do if the project is approved. Create a milestone plan to help the reader
understand the steps from approval until project closure. Be positive.
4.2. Avoids Confusion
Have you contradicted yourself in the document? Make sure you are consistent with your
naming conventions. Check your figures to make sure they all add up correctly. Carry out a
spelling and grammar check.
4.3. Enough Information to Decide
Put yourself in the shoes of the approver, and ask whether you have sufficient information to
make a firm decision to approve or reject this project. If you find you have questions, then
you haven't provided enough information.
4.4. Maintains Forward Momentum
Show how you will keep the project moving forward. Identify any obstacles you need to
overcome and explain how you intend to overcome them. Show that once approved, the
project will move forward in a timely and controlled way until its conclusion.
4.5. Moves the Organisation Forward
Explain how the organisation will be different after this project delivers.
5. Yield Optimised
5.1. Quantifiable Benefits
What are the benefits your project will provide? List them in the proposal with details of how
you will measure them. If you expect to achieve ten percent uplift in sales, say how it will be
produced and later measured.
5.2. A Good Fit With Strategy
Say why the project is a good fit with the organisation's strategy. If it doesn't fit, explain why
it should be approved.
5.3. Optimised to Produce the Best Return
Show that you have tuned the project to provide the best Return on Investment (ROI). If you
don't have a high ROI why are you proposing the project. Are there regulatory, security or
legal reasons? If so, explain what they are.
5.4. Realises Benefits
Explain what you intend to do to ensure the benefits envisaged at the start of the project are
realised at the end of the project. What will you have in place to measure and confirm the
benefits have been delivered? Keep in mind that most benefits are realised well after a project
is closed.
When you next propose a project, take a moment to consider whether your proposal is
relevant, engaging, authoritative, directional and yield optimised. Remember the
mnemonic READY and produce a proposal that's difficult to ignore.

6 Steps to Turning Around a Financially Failing Project – Part 1

There are many ways our projects can take a turn for the worse. We can miss crucial
requirements early on, leaving us to duke it out with the customer over who is responsible for
the oversight. Processes can take much longer than anticipated, throwing our timeline way off
schedule. We can have our project team poached by other "more critical" projects that need a
particular skill set right now-the list can go on and on.
One more way – and it too can happen for a great many reasons – is for our project budget to
spiral hopelessly out of control.
Now, just to be certain, there is no quick fix or magic wand that will make the project budget
problem go away. At least not short of some very large and lopsided change request from your
big-spending-project customer with bottomless pockets. (If you find that customer, please
send him my way.)
But there are some actions you can take to gain control over a budget that isn't too far gone or
to make strides on gaining some degree of control—even over a project budget that seems
hopeless.
I'm sure there are many strategies – and I'd really like to get your input on steps you've taken
personally to get the project financially back on track. For now, though, my personal list will
be limited to six.
This post will cover the first three:
1. Share, Share, Share
I always say…share the financial information with your team – and anyone of importance
charging time to your project. The more they see real numbers, the more likely they will be
accountable for an accurate reporting of their time and effort to your project.
What do I really mean by this? At the end of the week, that last 5-10 hours of time that project
team members know they worked but really can't account for have to go somewhere. And that
somewhere is going to be the project whose project manager is NOT watching the financials
like a hawk.
If you discuss financials and any concerns with them regularly, then your project will not be
the one to get those "grey" hours charged to it. Trust me on this one. Better yet, try it, and see
for yourself.
2. Look for Revenue Opportunities
This is an obvious one. I'm sure your execs have drilled it into you, but always look for new
project revenue opportunities. For example, say you're mostly performing the project
remotely. However, the execs really feel more comfortable with the tech lead being onsite full
time.
This presents an opportunity for you to put in a change request. How? Propose that tech lead
as a full-time, dedicated, onsite resource for the remainder of the project.
I did that on one project with a business analyst. The result? It generated a quick $130,000
injection of revenue into the forecast and helped increase overall project profitability.
The lesson here is that you never know what your project clients are willing to pay for until
you try. The key is to ensure it is something that will provide client benefits and might be
filling a need you identify. Otherwise, they will think that you are just trying to pry money out
of their hands.
3. Review Past Invoices
It never hurts to review old invoices. I did that once out of desperation on a financially
unstable project—and found over $25k in unpaid invoice items. They were just oversights,
but it happens.
Every penny helps get the budget back on track.
Projects fail for many reasons, but I believe that the hardest one to handle and to dig out from
is the one that is heading for financial ruin. As a project manager, you can gain time—
sometimes just because your customer is slow to respond with approvals and so on, which
happens all the time—but it's challenging to gain dollars. In part 1 of 6 Steps to Turning
Around a Financially Failing Project, I covered the first three of six steps. Here in part two of
the article, I will examine the final three steps. As always, I welcome your own thoughts,
strategies and experiences with trying to right size the project budget that has gone out of
control.
4. Pay Closer Attention to Scope Creep
As a project manager, you must constantly pay close attention to the scope of work on the
project. It's very easy to start gold-plating work—even without realising it—just to increase
customer satisfaction. You should also watch what you say "yes" to, what your team is telling
you in status meetings because they are sometimes working closer to the project client than
you are, and what your project client is requesting. You don't want to be that project manager
who is constantly saying "no" or who is always yelling "that's out of scope!"—although you
do need to watch scope carefully. Never perform work you aren't getting paid for, and never
propose customer request change orders that are clearly out of scope. Controlling scope will
go a long way in helping your project stay, or get back on, its financial track.
5. Move Phases Around
This one is more likely to help with timeframe issues than budget issues. However, it may
allow you to use less expensive resources or a discounted third party contractor strategically
while not upsetting the client if certain phases of a multi-phase project can be moved around
without disrupting the final outcome or schedule. Moving phases around may not help a
financially failing project, but it may be worth looking into.
6. Review Resource Forecast for Over Extending Effort
Finally, look at the revenue forecast. Can you decrease estimated hours on a few tasks here
and there and get the same work done in less time? There may not be much financial gain on
your forecast, but it may help by several thousand dollars—and every little bit helps unless
the situation is already completely hopeless. Play with different scenarios and definitely
discuss this with your team before you make any project schedule or financial/resource
forecast changes official as they are the ones whose effort you would be adjusting. You don't
want to plan your financial success on anything that is actually impossible.
Finally
These are my top six steps or actions. There's no guarantee that these six actions will work for
every project, but they will help on most. Any action is better than no action, of course. Now,
I'd really like to hear from our readers. What actions have you taken to help a 20% budget
overrun return to alignment with the original financial plan? What strategies can you share
and discuss here as possible ways to fix the project revenue or profit margin issues?
How to Report Status on a Project
 Best Practice |  By Rob Redmond |  Read time 9 minutes
Your boss has asked you to take the lead on a project in your company. Maybe you are a
project manager, or maybe you are not. One thing is certain. Very few people know how to
report status on a project, even when they are expert project managers. The basic problem?
Most people do not understand the perspective of a manager who is being pressed for
information about a big project. Here are some basic rules of reporting status that you can use
to further your reputation as someone who knows how to keep management and the project
team informed and drive a project to success.
The Management Perspective
If your project is important, your boss will be pressed hard to keep his superiors informed of
its progress. Smart managers consume status on important projects voraciously. Excellent
status reporting means that managers are fully informed of your projects health and overall
direction without having to get involved themselves. There is particular information your boss
needs in order to show her boss that she is on top of things and able to run the show
effectively. Provide this information in a way your boss can consume it on a regular basis, and
you will fall upstairs so fast your head will spin.
Even on relatively less important projects, effective status reporting allows your boss to spend
only a few seconds skimming your report to determine what sort of progress you have made.
Excellent status creates clarity from confusion. Your job as the manager of a project is to take
a swirling, chaotic cloud of information and distil it down into its most basic elements and
then present them so that hundreds and thousands of hours of work can be understood in 30
seconds.
To write excellent status, you must understand:
The three components of status.
How to write brief details.
What key data is needed by management.
Three Components of Status
There are three major components to reporting project status:
Overall: We need to see the overall project health. As managers, we want to be able to detect a
project in trouble. We also want to help make that determination sometimes. You might not
know everything we know despite our best efforts to communicate. Your project might not be
as healthy as you think it is.
Milestones: Your project has major accomplishments which must be completed by specific
dates. We managers want to see which milestones are complete, which ones are in progress,
and which ones are coming up next. This allows us to analyse the schedule and decide to
either feel comfortable with it or challenge it.
Issues: Your project also probably has one or more obstacles to completion which have been
discovered. We'd like to see brief details about each issue so that we can make a decision
about whether or not to step in and help if necessary.
Organising Your Status
Just as you would clean a kitchen by starting up high and working your way down ultimately
to the floor, project status is best when it starts off with the highest levels of detail and works
it way down to lower and lower levels.
Thus:
Overall project health comes first. If I like what I see here, I can stop reading the rest. Major
milestones follow overall project health. If I don't like the project health, or if I am in need of
further details, I can read a little further and check out the scheduled dates we are driving
toward and your progress on them. Issues may be holding up those dates, so when I see a
problem in your project schedule, I can read further and see what it is. Really slick project
managers report the issues in priority order showing the issue causing the most jeopardy to
progress first.
Brief Details
Your job is to report on the details of your project in concise, crisp status that we can consume
rapidly without having to spend much effort on it. It might take you thirty minutes to write
your status, but always remember that your manager does not have thirty minutes to spend
reading it. Your manager realistically only has about 30 seconds to consume your status as
they may have 30, 40, 100, or even exponentially more projects for which they are
responsible.
"Brief Details" may seem oxymoronic to a project manager, but to a supervisor with a team of
project managers, it is not. There is enormous value in a project manager who can report
status without narrative. My recommendation is that you write as though you were creating an
old-fashioned telegram. More information about how to do that is coming.
Brief Details?
How can you provide details without being long-winded? It is a formidable task that most
never master, but it is not impossible. Here are some suggestions:
Write in bullets, not in prose. There shall be no paragraph anywhere in your status.
Avoid unnecessary use of titles and colons. We can see that 7/4/2008 is a date. Writing "date:
7/4/2008" does not tell us anything that "7/4/2008" does not.
Reduce, reduce, and reduce some more. Do your best to shorten all expressions and sentences.
Avoid adverbs (really, very, much) and avoid adjectives (good, bad, ugly).
Key Data
Management will need certain data from you in order to see overall health, performance
against milestones, and the threat that project issues present. For overall project health, these
data points might include:
The project's name
The project identification number if your company uses a tool to store projects.
The overall project health (red yellow green - more on this in a future article).
The % complete you expected to be at today (planned completion).
The % complete you are actually at.
The number of days behind or ahead against the plan.
The number of blocking issues you face (more about this later in this article).
The number of "normal issues" you face.
These data elements should provide a sound overview of project health for the average
executive who is not details minded and is not interested in getting more involved in your
project.
If I am your supervisor, I need to see more than just the overall health of the project. I also
want to see where we are against certain milestones so that I can make a decision about
whether or not to get more involved. One of the hardest things a manager has to do all day is
decide whether to give you more room or get into your work with you. We don't want to carry
your work for you, but we also don't want you to fall flat on your face.
Providing project milestones is helpful in this regard. It lets us see your schedule at a high
level, determine if the schedule is acceptable as it stands, and predict pitfalls you might face
down the road.
Milestones have six components:
The milestone name.
The percent complete of the milestone.
The planned start.
The planned finish.
The actual start.
The actual finish.
Some people like to provide red, yellow, green (RYG) status for each milestone in their
project. I don't believe that adds any value. Of course the completed tasks are green. They are
complete! All following milestones have the same status as the current milestone, so there is
no point in differentiating them. The RYG status of the whole project is all that is necessary.
It's best to start with the earlier tasks first and the final delivery date at the bottom. If you list
them haphazardly, you will create more confusion than clarity.
Issue Management
The final portion of your status report is to list the major issues your project faces. Important
data that we need on your issues:
Ticket number: if there is a ticketing system, give us a link to the ticket or the number of the
ticket.
Issue name: this should be very descriptive and brief.
Date and time reported: we need this to see ageing. The older an issue is, the more likely
someone is going to get in trouble for not solving it faster.
Priority or severity of the issue: your issue is mega-important if it is a "blocking issue." If the
problem is stopping the project from moving forward and is single-handedly responsible for
endangering the delivery date, it is a blocking issue and is very important. If the problem is
just another bug in some software that will be resolved in short order, it is not as important.
Who has it: the name of the person who currently owns driving this issue forward.
ETA: Managers are like children and always want to know when they are going to get
something. "Are we there yet? Are we there yet?" Provide a time and date for when the issue
will be resolved. If you cannot, then provide a time and date for when you will get to the next
step in the issue resolution process. If you cannot do that, then provide an ETA for your next
updated status on the issue.
Current Activity: What is currently being done to resolve this issue? Are you firing up a
conference call? Are you calling out for reinforcements from a particular group? What is
being done to mitigate? Are there alternatives?
Expected Results
If you produce really great status on a project and provide it often enough and to the right
people, which are great topics for future articles, you should expect one of two results. Either
management will become very quiet and not engage with you very much, which usually
means they feel you are on top of the project and are capable of operating without their
intervention, or they will increase their communications with you in order to ferret out further
details and determine if they need to intervene.
Either result is better than the alternative: Management asking you for status. Your job as a
project manager is to create clarity from confusion for the project team and for management.
Essentially, the job is one of analysis and communication. If management is asking you for
the status, either you are not sending it to the right people, you are not sending it often
enough, or you are not sending a good status report.
Management should be able to passively absorb your status without having to reach out to you
to find out where things are at. The pace at which you send it, the audience you select, and the
content of your communications should be available to them easily and quickly.
A project manager that can status a project skilfully and briefly is a rare find. It should not be
necessary to create colourful slide shows or multi-page documents in order to provide really
great status reports. Many go that route and drown management in errata. Narratives and
prose are always unwelcome in status reports, and yet so many write as though they were
authoring a novel and create a report that management must spend inordinate amounts of time
with in order to get what they need. Others fail to provide enough information at all, or worse,
they provide status irregularly or rarely.
In all of the project management training and certification systems available today, almost
none teach how to report the current state and next steps of a project. Learn to status your
projects effectively and you have a competitive edge that goes beyond the standard project
management toolkit.
Rob Redmond studied sociology, psychology, and political science as an undergraduate,
eventually receiving a Masters of Business Administration (MBA) from Georgia State
University in June of 2000. He is currently employed as a manager in the information
technology division of a large technology company.
Rob has long years of experience with the Japanese language and the Japanese martial arts,
and brings these concepts and basic management principles he has learned along the way to
produce articles which reach out to others who struggle at work.