When senior management asks for changes mid-project, how do you keep things on track? What’s the difference between report status and a status report? How do you narrow down a list of project assumptions? Read on to find the answers.

Follow scope change process; let the project sponsor make decisions
Donna, the project manager on a large marketing information database project, stopped by my office recently. The current system uses a decision support and reporting tool to write a series of standard reports for senior management.

“I thought we would have more than enough time to complete the identified standard reports,” Donna explained, “but now that we’re halfway through the estimated timeframe, we’ve only completed a handful of the reports. At this pace, we will have a major deadline overrun.”

“What’s the cause?” I asked. “Did you just underestimate the time it takes to write the reports?”

“No, but the senior managers aren’t used to having this type of information available to them,” she said. “Now that they’re seeing the initial reports, they’re requesting all types of changes.”

“This shows your managers are interested in the reports,” I said. “But you’ve been around long enough to recognize scope change. Are you using your scope change management process?”

“That’s the tough part.” Donna said. “These are senior managers. It’s hard to tell them that they can’t have changes.”

I sensed that Donna was falling into a typical trap when dealing with managers. I reminded her that scope change management is not about saying “no.”
One of the reasons project managers hesitate to invoke scope change management is that they believe they’re saying ”no” to the business client and aren’t being customer-focused. Scope change management is actually a process for dealing proactively with change and the effect it has on the project. There are certain assumptions made when the project estimate is produced, including the features and functionality of the deliverables. If changes are requested, the business benefits should be considered along with the impact to the project in terms of time and cost. The project sponsor can then make the determination as to whether to accept the changes, along with the corresponding changes to budget. In Donna’s case, her sponsor might approve the changes and the corresponding change to cost and schedule. Or, the sponsor may decide to proceed with the reports as they were originally designed. In either case, it ends up being a decision made by the business client, not the IT project team. A solid scope management process is a project manager’s best friend.
Report status vs. status reports
James is in the IS development organization and currently manages a project to install document management software for the legal division.

“My sponsor saw a report on the desk of the finance director that shows the status on a big project in the finance area,” he told me recently. “My sponsor started to ask questions, and now it turns out I need to do a status report as well.”

I asked if he reported status.

“No,” James said. “Now my sponsor wants a status report the same as the one from finance. This report is four pages long and contains more detail than we track here. It’s going to take us a long time to do this report—time we could be working on the project.”

I asked James if he considered communicating with business clients to be part of his work on the project.

“We were communicating fine without having to do a four-page status report,” he replied. “We always took time to let the client know what was going on whenever they asked. It’s all this paperwork that turns people against methodology.”

“Let’s be clear on this,” I suggested. “There’s a difference between ‘reporting status’ and ‘status reports.’”
In the old days, a good project manager may have gotten away with being a poor communicator. Today, however, projects need to be undertaken in partnership with the business. The partnership absolutely requires solid two-way communication. The IS team and the client don’t like surprises from one another. Proactive and ongoing communication is the key to making it all work. I ask project managers to report current project status to all interested stakeholders. Many people are comfortable communicating this status through a formal status report. Other projects send out a status through voice mail, collaborative technology, or the intranet. James needs to do a better job communicating with his business client. The status report prepared for the finance sponsor may not be what he needs for his project. He should work with his sponsor and his manager to determine what communication mechanisms make the most sense.
I received an e-mail from Lori that contained a draft copy of a project definition. One area that missed the mark was the section on project assumptions. Lori listed 24 separate assumptions. This immediately caught my attention, and I went to see Lori so that we could talk about the definition of an assumption.

On most projects, there are events and circumstances outside the full control of the project team that must occur for the project to be successful. If it’s likely that the event will occur without outside intervention, it should be identified as an assumption.

Using that definition, I went down Lori’s list to the first few assumptions:

  1. The project would have the resources necessary to complete the work. Project teams usually don’t have control over all of the people, hardware, software, and dollars necessary to complete the work. They require management assistance and intervention. Lori felt confident that she would have the resources she needed, so this one is a correct assumption.
  2. A pilot test would be conducted before the solution is put into full production. This does not fall under the definition of an assumption because it is within the control of the project team. This statement is actually a part of the project approach.
  3. A new server must be installed. I asked Lori whether this was likely to occur. She said that it was. In fact, the server had already been installed last week. Based on that information, this statement is not an assumption. It is just a fact.

Lori was getting the point. After that, it was quick work to reduce her original list from 24 to only five true assumptions.
Assumptions describe events, circumstances, and conditions relied upon for the project to be successful. They’re not just attempts to deflect blame if the project is not successful. Assumptions provide a basis, or context, that explains how estimates are prepared, how dates are assigned, and how scope statements are defined. The rest of the project definition is predicated upon these initial assumptions. There are three quick tests to validate whether a statement is really an assumption or not:

  • The assumption must be outside the total control of the project team. If it’s within the control of the team, the team is responsible for making it happen.
  • There must be some degree of uncertainty to the assumption. If the statement is 100 percent true, it’s a fact. Likewise, if the event has a zero percent chance of occurring, it is irreverent to the project, and is also not an assumption.
  • If you need the event to happen, there must be a good likelihood (better than 50/50) that the event will occur. If there is a better likelihood that the event will not occur, it’s more likely to be a risk. (One caveat is that an event that is likely to occur could still be a risk, if the result of being wrong would have a major detrimental impact on the project.)

Project management veteran Tom Mochal is director of internal development at a software company in Atlanta. Most recently, he worked for the Coca-Cola Company, where he was responsible for deploying, training, and coaching project management and life cycle skills to the IS division. He’s also worked for Eastman Kodak and Cap Gemini America, and has developed a project management methodology called TenStep.

Tell us about them. Tom Mochal may consider answering your question or addressing your problem in an upcoming column. Post a comment below or send us a note.