Do you remember where you were the day that the Space Shuttle Challenger disintegrated before our very eyes? It was a brisk Tuesday morning on January 28, 1986. That’s over 25 years ago but it’s etched into our minds as if it was yesterday. The shuttle took off and then slightly over one minute into the flight it came to pieces.
A National hush fell over the country as the impact of such a disaster began to soak in. It was quickly learned that all 7 astronauts aboard the space shuttle had perished. The President, Ronald Reagan, spoke to the country that night about the disaster that occurred earlier that day. The Space Shuttle program was grounded for nearly 3 years as a result of this cataclysmic event.
What happened? The reading is fascinating about all the conversations and warnings that were held prior to the Shuttle taking off. But, it came down to an O-Ring that did not properly seal.
One of the main reasons attributed to this is because the temperature from the night before and the temperature during the launch were colder than usual. The threshold for these O-Rings to properly function and seal at such cold temperatures had not been tested nor identified.
The above disastrous example highlights the importance of knowing the thresholds, testing the boundaries, and adhering to such limitation. The consequences can be profound.
It is certainly hard to correlate what we experience in our daily jobs as project managers to the event that occurred on January 28, 1986. However, it does allow us to reflect on the importance of setting and respecting thresholds and reporting project activity against them within what we do as project managers.
Thresholds and Project Change Control
There are forces that are exerted on our projects every day. We can implement whatever project management program we see fit, but we have to understand that pressures will be exerted on nearly each and every task that is undertaken. These forces range from resources taking longer than originally expected to requirements being totally wrong or missed on a project.
It’s a project manager’s job to exert their influence in these areas in order to keep a project moving forward.
One area that comes up time and again is the force of a client or end-user wanting to change something on a project that is already underway. Not only is it underway, it was agreed upon that what is underway is exactly what the client or end-user needs. Everything has been set and ready to go in the project management program… and now there’s a change in plans!
This reality has caused many to overreact in the project manager community. Here’s an example: A client is working with a company to put together an Hours and Attendance application. This custom application will allow their employees to check-in/check-out at the front desk and then either get on with the job at hand, go to lunch, or head home.
The client decides that the originally agreed upon green tint of the ‘check in’ button needs to be a shade or two darker. “Sure, no problem,” the project manager says. “Let me put together a Change Request form to make sure we capture this request. This will of course take our Engineering team a few days to determine the scope of the work, our testing team to see how long it will take them to make sure the change is made.
Then, we’ll of course need to get executive approval on this color change prior to coming up with the final amount that that this change is going to cost. We’ll then present this to you, probably after two weeks, and then based upon your approval we’ll schedule this button color change in to our project manager program and get it done in the next couple of weeks”.
As ridiculous as that sounds, these types of conversations take place. They unfortunately take place for a valid reason. This is because resources, project managers, and companies have been burned by the incessant stream of one-off change requests that the client feels are necessary to get things right.
There’s no project management program in place that could keep up with some of the requests that end users will make of the project team. Unfortunately, this has caused some end-users to just roll their eyes when a project manager brings up the words “change request”.
Is There a Better Way to Manage Change?
Is there a better way to manage change requests?
Is there some type of project management program a PM could implement that would take the absurd out of the equation? Yes, and it relies upon thresholds.
This type of project management program isn’t necessarily ideal for all projects. You may work on a project or in an environment where changes are few and far in between. In that case it wouldn’t make sense to implement such a project management program to manage to change. If, however, you work in an environment where change is the only constant, then you may want to consider this approach.
The secret to managing change through thresholds relies upon the following categories:
- Small Changes: Minor changes in this project management program are those changes that can be made in no time at all. These changes will have zero impact to cost, scope, delivery, or quality of the project. They are typically cosmetic in nature and even if something goes wrong with the change it will not negatively impact other areas of the project.A perfect candidate for this type of change? The client wants to change the color of the button from a light green to a dark green.The project manager will be able to accept and approve this type of change if it meets the criteria above. There’s no reason to jump through all the hoops mentioned at the beginning of the article to obtain approval. By the time all those hoops are jumped through, the change could have been made and everyone moved on to other components of the project.This doesn’t mean that the change is not documented. It’s important to keep a record of everything that changed, but it’s as simple as putting it in a change request log and then letting the team know to make the color two shades darker.
- Medium Changes: Medium changes are a step above small changes. These may cause a slight change to the cost, scope, delivery, or quality of the project, but not big enough that it alters the overall business value of the project.A project management program for implementing this type of change could be to present it to a Change Control board. This would be comprised of yourself, the client, and one or two other people in your company (such as a functional manager or executive). The object would be to get all to agree upon the change.Again, this should take a matter of hours to complete and not be dragged out over days or weeks. A simple form can be used with signature lines for everyone’s approval and then the change can be implemented.
- Large Changes: The last category are large changes. These types of changes and approvals justifiably will take longer to approve and implement. These are the types of wholesale changes that could cause the ROI of a project to change or the business value to erode. These are the types of changes that call into question the need to even continue with the project. A project management program or process needs to be put in place to ensure that executives in both companies are aware of the impacts.
There will never be a comparison between what happened to the Challenger and what happens in our day to day position as a project manager. However, we can appreciate the importance of setting and respecting thresholds to ensure our projects are successful.
We have software that will help you manage the changes that you will encounter on every project. You can create different views for different users to create and approve change requests. We use 128 bit encryption so ProjectManager.com is as safe as online banking. Each customer database is separate from the rest, plus, you can choose who has access to which projects ensuring your security at the finest level.