Hello my friend,
In this blog notice I’d like to share with you some insights about changing the project scope and its consequences, if it’s done without proper planning and preparation. These insights are based on my experience that I’ve got the last week, so my wounds are quite fresh. Let’s go.
As it was and it is with my CCIE preparation, the preparation for PMP is kind of structuring the knowledge that I’ve gathered before and mapping them to my experience. For sure I’m learning new things and processes, but I want to cover a practical case in this article.
Categories of project constrains
If you are familiar with PMBOK or other project management practices, which are based on PMBOK, you know that one of the important and essential tasks for project managers is to balance between scope, quality, budget, time and risks in order to meet project requirements and achieve project goals. Let’s take quick look into each category:
- Scope refers to the all activities that must be in project to achieve their results and meet its requirements
- Quality is a measurable characteristics of the project deliverables, which shows how they satisfy project goals
- Time is a limited period that shows which amount of time we have to do all activities
- Budget refers in overall to all the resources (like money, team members, goods and so on) that we need to accomplish the project.
- Risks mean positive/negative factors, which influence the accomplishment of the project within defined time, quality and budget.
In PMBOK there are at least 6 definitions, where the 6th is resources. From my understanding there is no necessity to consider them as a separate category as it’s fully compliant with budget category.
Simplified overview of the project scope as a box
All of the mentioned categories are interdependent. If you change any of the project’s categories, at least one another will be changed as well. Imagine a project as box, where each of its sides is quality, time or budget.
The math here is very simple. The overall volume of the box is the scope of the projects.
To achieve the project goals you have to do certain activities, which is actually the scope of your project. Such scope can be realized with certain quality using some amount of time and resources.
But let’s back to our box. You know that it has limited capacity in liters. Under normal circ*mstances you can’t put in the box more things than its overall capacity. Let’s say you pack the books in the box. If you do it carefully, you can put a lot of books in your box and then pack it.
It’s successfully planned and performed project. You even have some place for some other books.
Now what about bad planning or the willingness to put too much books? Your project will look like the following image.
You can’t pack them. Maybe you can try to put them more careful but you still have a risk not to fit the workload in the scope. So you just need another box, read as another combination of the time, budget and quality. That’s the core idea of this article. You can’t change project scope without risks to fit in time, quality and budget dimensions. It’s basic of project management, but sometimes people try to pack unpackable.
Real case
The last week I performed some reconfiguration activities in production network. I made a plan for the work with explanation of their causes to my manager. My task was to change BGP configuration in quite complex environment, including introduction of new features and change of route policies. The plan also contained the description of each activity with necessary steps and schedule. So I was absolutely ready for the work and just waited for the maintenance window.
When it came, I’ve started the network reconfiguration activities according to my plan with activation of new features for BGP. My work was part of more global maintenance activities, so I did it together with my colleagues, who were responsible for testing the application part. We had a definite size of maintenance windows, so we had to follow our schedule in order to be able to accomplish all tasks in time.
After the first part was successfully done, one of my colleagues said that he need change some BGP policies at load balancer. I was not aware of this activity, because at the preparation stage I wasn’t informed about. As our BGP environment is quite complex, we’ve failed to change that BGP policy ad hoc and spent a lot of time on troubleshooting. Such new object to the scope of my project (network reconfiguration activities) led to that I failed to accomplish all my tasks.
The next day I analyzed the changes in BGP route policies that were asked by the colleague and found the issue. If I had been informed by server guys in advance, that they needed some changes for BGP route policies at load balancer as well, we wouldn’t fail.
Project plan isn’t something unchangeable. It must reflect all the changes in goals, environment, scope and so on. But such reflection involves also a change in necessary time, budget and quality.
Lessons learned
This case refers both to proper change management and project management. But as I’m focusing myself at project management part in this post, I want to underline the fact, that change in project scope increases the risks to fail, if all other categories like time, quality and budget aren’t changed.
We did have longer maintenance window or more engineers to accomplish this task. So my box was the same, as it was from the beginning. But I had to put a new book there, though there was no free space. The result is predictable.
I wish you success in proper project planning and its updating.
Support us
Best Regards,
Anton Karneliuk
BGPbudgetinterdependenciesproject managementqualityreal casescopetime
