Never assume. Always assess first.
While assessing the goal, always check the grand settings. Understand the direction of the momentum, the scope, the time line, the metrics and the risks.
Our Compass AE process is based on defining the outcome first. Once it is delineated, one understands the direction of the project. Then it becomes easier for the project strategist to establish the operational specifics of the project.
We will touch on the topic of top-down thinking in later posts.
When You Assume
Andy Clark
April 1, 2009
The plan looks good on paper. Competent professionals are executing it. But unexpected delays and costs still crop up. It could be the one area of project management where your years of experience can actually hurt you: assumptions. So how do you weed them out of your plan? Here are some unassuming ideas.
It happened to me again last week in the initiation phase of an Archiving Implementation project. We completed a successful proof of concept and were moving ahead with the implementation, which required a refreshed database. I had asked the database administrators (DBAs) how long it would take to build the refresh and they answered “4 hours.” I assumed this was a full estimate of the time required for the refresh, based on my experience working with DBAs on similar activities. What I didn’t realize is that changes in storage technology had changed our refresh procedures and this was now a System Administrator operation as much as a DBA operation. Consequently the estimate did not include either the System Administrator work or the coordination work.
I hadn’t waited until the last minute to get started, so this false assumption didn’t cause a delay in the project’s critical path, but it did cost some of my time and caused work to be done on a quasi-emergency basis rather than as a planned activity.
Every time I turn around, I run into an assumption. I’ve seen system tests delayed because lab configuration wasn’t complete; rollouts delayed because user documentation wasn’t in a usable format; and meetings delayed because key participants were on vacation.
Many times I’ve seen a plan that looks good on paper, executed by qualified professionals, get hammered with delays caused by assumptions. It’s easy to do, and it’s the one area of project management where your own experience can actually betray you. You evaluate and estimate an activity based on previous experiences, but don’t realize that there have been changes in the business environment that render these estimates invalid.
How do you avoid falling victim to assumptions? Here are some techniques that can help:
· Review your requirements and deliverables
· Question estimates
· Know the project team
· Consider stakeholders
· Pay attention to risk management
· Don’t be afraid to ask the obvious question
· Document (!!)
Carefully reviewing a project’s requirements and deliverables can identify many assumptions as you build the WBS, schedule and the other planning documents.
For example if a project requires status reports, who will draft them? How will the information be gathered and distributed, and in what format? Where will they be retained? Is there any special content that the sponsor or other stakeholders are looking for? Is there a specific time they want to see them and what time period do they want covered? Is there a part of the project they (or you) are particularly interested in tracking? Are there any accessibility or language considerations? Many of these questions have simple answers that will be right 99 percent of the time. However, notice how many questions come up for building status reports, and this is usually a very straightforward deliverable. By the time you finish walking through a moderately complex project there will be hundreds of these questions and your chances of missing one of those “99 percent certainty” questions is quite high.
You should always examine any estimates closely, even those you make yourself.How confident is the estimator? What resources is he or she depending on? Which of these resources do you not have firm control over? How much coordination and communications are required for the task? How recently has the estimator done this type of work? Generating an estimate that states, “We’ll need a developer to spend 16 hours developing a login page” is not enough. It is crucial to identify all of the resources and coordination required for each task. Otherwise there is a good chance that something will come up — for example, the coder will not have access to your directory services system for user authentication and you’ll lose a week waiting for that to happen.
Now you are ready to take a close look at the project team. Are there tasks that require a specific skill-set that is not on your team? For example, does your project require DBAs, or some other specialty, for several key tasks? If so, you should look to add or reserve someone with the right skills on at least a part time basis. In a similar vein, you also need to be careful when project staff has other commitments. When you have project members on multiple projects you need to be sure you know where your project falls “in the stack.” When your project members also support operational systems this can take them completely off your project at any time. Be prepared.
Always consider the stakeholders. Some project managers fall into the trap of paying so much attention to the project team’s requirements, that they ignore the stakeholders requirements. Many projects depend heavily on stakeholders for training, testing and documentation activities. Virtually all projects depend on stakeholders to verify and accept deliverables. Give careful thought to what stakeholders will need to perform their duties. If you are relying on stakeholders for testing or verification, they will likely need help in defining test plans and test cases. Consider what type of training, access and reports your stakeholders will need. Investing time in helping your stakeholders be effective participants is time well spent.
You may have noticed that the type of work you do in identifying assumptions bears a strong resemblance to Risk Identification. The two efforts really do work hand in hand. Any assumption is a risk, so doing due diligence in risk management will help you identify assumptions and vice versa. In addition, you should be alert for new assumptions when you are working your way through Risk Analysis and especially Risk Response Planning. If your contingency plan for losing your database server is to move your database to another server, then you are assuming that both servers will not be simultaneously offline for an extended period of time. Hopefully, these two servers are not on two virtual machines located on the same physical server.
Good project managers ask questions even when the answer seems obvious. Questions, even seemingly easy questions, make people think. When you ask the system engineer whether a 50-teraflop graphics processor can handle the forms processing video, he may realize that, while processor power is not a problem, memory and storage could be. The obvious question often is not as obvious as you think, and sometimes it leads others to spot problems that you might overlook. These types of questions will help you get the best from your team.
Finally, make sure that your assumptions are documented in appropriate places — the Project Charter, Risk Management Plan and Project Requirements Document, for starters. This needs to be done for all of the usual political reasons, but it also helps identify new assumptions. Writing documents and asking questions are the best ways to nudge team members into identifying new risks.
These best practices can help, but in all probability you will not identify all assumptions. It’s easy to overlook the possibility that a team member will be sick at a crucial point, a virus will infect your workstation, or that your sponsor will be transferred to a different position. In fact, it’s probably not worthwhile to try to find everything, but you need to do what you can.
In the case of my archiving project, the problem with the refresh did not delay the project because the refresh was not started at the end of its slack period. Slack time is a gift on a busy project. Typically that gift is spent working on other activities, but whenever possible, start tasks as early as possible, lest you discover that your project has a new critical path.
These concepts, like much of project management, are mostly common sense. However, if you believe that common sense is the same as common practice, then you are making a really bad assumption.
Andy Clark is a Lead for the Virginia Community College System, one of the largest integrated higher education systems in the world. In this capacity, he routinely leads projects with dozens of engaged stakeholders. His 25 years of project management experience encompasses projects of all sizes in both the public and private sector.
Copyright © 2009 projects@work All rights reserved.
The URL for this article is:
http://www.projectsatwork.com/article.cfm?ID=248406
http://www.projectsatwork.com/content/Articles/248406.cfm
No comments:
Post a Comment