So you think you know what it takes to fully define project scope?
My experience is that if you ask any Project Manager for a definition of scope, you’ll typically get a pretty good high-level definition. True, it will be textbook. Clinical. In fact, here are a few that I’ve come across recently:
- objectives for a given project, how the objectives will be achieved, and the boundaries within which the project will be delivered;
- goals of the project, amount of effort to meet the goals, timeline/milestones, budget, work delegation, how progress will be tracked, resources required to complete the project;
- how a project will be delivered as defined by the project objectives, project plan, deliverables to be produced, deadlines, and budget.
There’s nothing inherently wrong with these high-level descriptions. They describe scope from the perspective of process. In my many years of project delivery experience, I have rarely witnessed a client disagree with such definitions.
Take, for example, the last of the three definitions above:
- yes, the clients have defined their objectives; those won’t vary
- yes, they have seen the project plan; but they leave that to the IT provider to manage
- yes, they know that there will be n number of deliverables produced; they’ll be sure to review and approve them when they are delivered
- yes, they’ve agreed to the deadlines; again, they leave that to IT
- yes, they have a budget; and from the client’s perspective, IT better manage to that.
However, where I have seen client organizations resist is with regard to the functionality they are expecting to receive. That is where their interests truly lie in terms of scope definition. What are they getting for their money? Will the project objectives be satisfied by the functionality they have requested? Will their end-users realize the benefits of the new system based on the business functions to be automated?
Here is my frustration with the process-oriented viewpoints noted above in developing the project scope statement. It seems that project delivery organizations tend to fall to process: those elements of scope dealing with project objectives, plan, deliverables, deadlines, and budget. It’s as though the client’s requirements are an afterthought or a necessary irritation in completing the project.
And yet it is the client’s definition of scope – the people aspects of the project delivery and the business and functional requirements – that really matter in any project. In the definitions of scope noted above, one would have to infer from those descriptions that the client’s main requirements for initiating the project are even under consideration.
We can do better than that. In my earlier article, “This is How to Develop a Great Project Scope Statement,” I related some ideas from my consulting work with both IT and client organizations. In this article, I will expand on those by offering ideas on preparing to control project scope as the project progresses and for future project executions. In fact, it may be advisable to allude to these concepts in the project scope statement.
- Select the best qualified project manager to “fit” with this client. I’ve witnessed projects become scope money pits, not because the client was overly demanding (ok, they were; but aren’t they all?), or the IT Project Manager was inept. My experience shows that the IT PM just didn’t click with the client or the client’s project staff. I’ve seen PMs who were weak in domain knowledge and lose the client’s respect. I’ve seen PMs who tried to impose by-the-book processes on their end-user project staff, and get immense pushback. I’ve seen PMs who felt the client staff were below par, and without understanding why or how, were sabotaged in their efforts to move the project along.
Perhaps the most egregious example that I witnessed was a Project Manager who arrived at the client site in a brand new luxury car – a very expensive luxury car – and parked in a reserved spot at the front of the building where it couldn’t help but be noticed. What worked in Los Angeles didn’t sit well with the client’s project staff from this small midwestern community, who spent their weekends fly fishing and tilling farmland. You probably surmised that she had a huge uphill battle in gaining the client’s cooperation.
What many IT providers don’t realize is that projects have their own personality and culture, and the assigned Project Manager must be prepared to conform to that personality and culture.
- Keep the understanding of the project objectives front and center. Projects will take on a life of their own, if we let them. Team members come and team members go, especially among the staff loaned to the project by the client, and especially on long projects. It is important that the project objectives and a firm understanding of the end results are continuously publicized for the duration of the project.
- Manage the client’s expectations – from stakeholder to end-user. Stakeholders require different level of communication than project staff. IT project staff require different communication than their end-user counterparts. But they all require clear, concise, transparent communication so that everyone is fully aware of project progress, needs, issues, risk mitigation, required changes, and other such project concerns. Everyone must be on the same page for the life of the project in order to maintain their commitment to the success of the project.
Such communication is a learned skill. But learned it must be. Communication and managing client expectations stop the urge to constantly tweak or re-think functional requirements. The end result is more likely to be what the client expected from the project. Project budgets are protected and schedules maintained.
- Define deliverables processes. Most client staff loaned to a project have “day-jobs” and don’t understand the concept of deliverables. In defining key phases and milestones, it is important to also define how each deliverable will be produced and delivered, and what their responsibilities are with regard to review and approval of deliverable.
But just defining their responsibilities is not sufficient. The client’s project staff need to be walked through the deliverables, understand how each is used, and how they are to conduct their review of the deliverable contents.
- Maintain awareness of each team member’s strengths and weaknesses. IT staff are selected for their skills and proficiency with technology and process. Client staff are selected typically because of their domain knowledge or overall specialty knowledge and experience in the business. However, not everyone is well suited to the rigors of project life. Monitoring team members’ contributions, maintaining awareness of their strengths and weaknesses, and making warranted adjustments are necessary to keep productivity high and the project moving according to plan.
- Treat risk management seriously. Each project has potential risks that must be mitigated in a timely manner, always keeping the project goals and objectives in mind. For risk management to be truly effective, project risks must be communicated frequently with all stakeholders and team members, and handled as quickly as possible when risks are identified. By managing the risk effectively, each team member will maintain greater confidence in a successful project outcome.
- Prepare project gate reviews with diligence. When the entire team is heads-down working their daily tasks, it is not easy to step back and look at project delivery with a critical eye. Incorporating gate reviews into the project management plan, and preparing diligently for these reviews, allows the project team to take a comprehensive view of the project’s progress. Project execution can be adjusted. Lessons learned should be documented and maintained in the project repository.
Above all, the results of the gate review must be detailed and communicated effectively to the stakeholders and project team members. It is only through their buy-in that continued progress can be made.
Similarly, when the project is completed, it should be reviewed and evaluated as a whole. Successes should be documented. Lessons learned should be memorialized. Staff should be commended. Gate reviews and end of project reviews are valuable processes to help reduce mistakes that might otherwise be made on future engagements.
Do you see why I am so adamant that, while process is important, we must pay attention to the people aspects of managing our projects to be truly successful? I repeat the following from a previous blog post: “These people-focused techniques are not difficult to learn and implement, and are instrumental in helping to assure greater project success. It’s time for IT to invest in the essential skills that attend to the people aspects of project delivery.”
If you want your IT projects to come in on time and within budget; if you want your clients to be your best ambassadors and your project teams to be committed to your success; if you want to stop leaving money on the table – then Merv Jersak is the mentor and coach who will work with you to help attain the results to which you aspire. With more than 40 years’ experience as an IT Project Management and systems consultant, Merv works with IT solution providers and end-user organizations, focusing on the people aspects of project delivery to drive more profit to the bottom line and to have fewer budget overruns.
To learn more about Merv’s service offerings, or to hire him to speak to your organization, visit www.PeopleFirstProjectManagement.com.
52 Project Management Success Tips from Merv Jersak • Copyright ©2020. All rights reserved.