Bad Project Scope & Unrealistic goals: What should you do?

“What to do if you have a project where the scope doesn’t fit the client’s wishes or just not clearly defined?”

Have you ever had a project where the project charter did not clearly define the project’s scope?

Have you sat in a project where the final product introduced by your company or project sponsor did not match what the client wanted? Projects equated to the upper managers telling the Project Teams to build a Hawaiian Grass hut with a state-of-the-art air conditioner for an Ice Fisherman in the arctic circle.

It happens that a client’s expectations do not meet what your team is to build, be it unrealizable target dates or a design for a beach house, but the client wanted a hobbit hole. In some cases, Project Managers have reported they were to build a product for a client who wasn’t sure what they wanted. So what should you, as the assigned “Project Leader,” do when that happens?

This article will look at examples of what happened and when the project scope was improperly defined or sponsors insisted on unrealistic dates.

Definition of Project Scope

A Project Scope and Project Scope statement defines the work required to achieve the project’s goals.

Scenario 1: Unclear Scope and No Proper Network Design.

Robert, an IT project manager, received the task of building a new cloud-based IT data center. The first thing the project manager and his SME (Subject Matter Expert) noticed was the scope in the Project Charter did not clearly define what kind of a data center, just simply “Cloud Based.” Not only that, the organization that assigned the project wouldn’t let him or his team speak with an actual representative of the client’s company. Only a designated “customer liaison manager” was allowed to talk with the client and relay the information to the project manager and his team. Robert also wasn’t allowed to know who the stakeholders were on the client-side.

Solution:

First: Robert escalated these problems to his management, who made it clear they would support him; if these problems continue, he should find a way to leave the project.

Next: Robert insisted on improving the Project Charter where the scope would, at a minimum, have a requirement to deliver a High-Level Design that gave clear instructions of what kind of storage, network, security, and other essential systems defined. From there, he could have his team create a proper design and start building the data center.

It appeared to improve the problem when the customer liaison manager came back with what seemed to be a project design, and Robert had his team start working on the actual Architectural Design to build the Data Center.

The project was ¼ of the way finished when the customer liaison came back stating there was a misunderstanding and the client wanted to use a different form of storage. This harmed the triple constraint, “cost, time, and scope.”

After Robert took this to his management, he carried out the requested changes, but more such changes continued five times. As a result, the project that generally should have only needed four months was now in its ninth month.

Finally, Robert had no choice but to demand he, Robert, and his team is allowed to sit with the client, or he and his team would leave the project.

In this case, as the contracting organization would only allow communication through their customer liaison manager, Robert was left with no choice but to excuse himself and his team from the project.

After this bad experience, Robert wrote a project report explaining why he left the project. Important to note, in all meetings, the project manager kept minutes where the contracting organization would sign off as having read and agreed. Also, he made sure to have communication in writing, mainly through email, which is considered “Informal written” form and presented this in his report to his management.

Result:

To keep this from happening in the future, Robert worked with his upper management team to put together a list of requirements for taking a project. In addition, Robert and his upper management used all the lessons learned from this bad project, and all projects they worked on since have not had such problems.

On the side of Robert’s client’s customer, because of the constant changes and delays caused by them, the customer of the organization working between Robert’s team and them found a new provider that would allow them to work directly with a project team like Robert’s and not with a “Customer Liazon.”

Scenario 2: Unrealistic schedule:

Laura, a construction project manager, received a project where the sponsors demanded that she have a unique furniture warehouse put up in three weeks. Putting up a warehouse in this time frame usually would have been doable. However, this project requires a marble floor with stones not yet ordered, shipped from overseas. All suppliers she asked said they needed four weeks to deliver. Even if she fast-tracked the project, this would cause a delay in the time constraint of the triple constraint, and she would need five weeks to complete the project, and three was not possible.

Twice, when Laura explained this to the project sponsor, the sponsor would reply, “You are the project manager, find a way to make it work.” There was no way Laura could make the delivery faster.

Solution:

The first thing Laura did, was to go back to the original Project Charter and the original requests from the client. The scope definition was to build a warehouse for furniture that would arrive eight weeks after the planned completion date.

She also learned the marble floor was not in the original scope statement and was a part of a change added by the project sponsor before Laura was assigned to the project. Unfortunately, the project sponsor did not consider a change to the project scope when adding this change.

Next: she went over a plan with her SMEs and learned the marble floor has no dependencies on any of the work done in building the warehouse. Therefore, they could schedule this floor as the final task in the project plan and only needs one week to install after delivery.

Finally: As she knew trying to speak with the project sponsor again would bring the same answer, she called for a stakeholder meeting with all stakeholders who had a say in the project.

She presented a project plan showing how having all tasks before the needed installation of the marble tiles would be completed in less than three weeks.

She then showed a review of the original plans from the project charter, showing how the marble tiles added after creating the original charter and plan caused an effect to the original schedule. Finally, she explained, because of the dependency of the marble stones to be delivered and the expected delivery dates.

She ensured all stakeholders understood the new completion date would still give the client six weeks before the furniture would arrive.

The result:

The stakeholders all accepted her new delivery date.

Summary

These scenarios are only two of many such instances. In each case, to have a project run on time, a project must involve all stakeholders.

Scenario 1:

In a case like the first scenario where a project manager is not allowed to work with all stakeholders, the only solution is to walk away.

A project team must be allowed contact with the client. This is imperative as using a liaison working as a go-between to get important technical details is subject to misunderstandings. Furthermore, it will result in the delivery of an inferior product.

Scenario 2:

In this case, which happens very often, the original plans are changed, without understanding the effects to the triple constraint, before assigning a project manager. In this case, a project manager must take the lead and ensure the plans handed to them fits the original agreements with the customer. When a problem such as Laura’s warehouse project, the project manager should not be afraid to point these problems out at the start.

In all projects

A crucial part of project management is communication. A project manager must have written documented proof of all critical decisions. When a decision is made, it is advisable to have it in writing. A good example is keeping up good meeting minutes in calls. When keeping “meeting minutes,” it would be advisable to immediately get all stakeholders to look at a copy and get a written reply of the agreement.

Author

  • Ken Tillery

    Ken holds a Master of Science in Global Management and currently works as a Global Project Manager and has worked as a Global Service Delivery Manager. Ken spent the last 15 years leading globally dispersed teams with team members located in multiple countries. Has also given classes on how to deal with cultural differences and related issues when working with project teams with members located across borders and continents.

Recommended articles