Scope creep: when leaders allow uncontrolled changes, add-ons, and embellishments in a project’s goals, deliverables, features, and/or requirements.
When did I first learn the dangers of scope creep?
It was in a project where scope creep was all but eliminated—in advance.
A life insurance company was embarking on a system-wide computer software conversion. It was one of the smartest organization changes I ever saw.
This company’s leaders approached their conversion with caution. They knew many horror stories about how mismanaged IT conversions had destroyed major insurance companies. They learned it was critical to organize all their relationships and resources involved before ever starting their project.
The top leaders kept this project’s scope on a tight rein. They decided—before its start and almost two years before their conversion went live—to set up a unique leadership structure. This structure was to manage the entire software development and roll-out. Their structure incorporated the many roles needed to run their daily insurance company operations while folding in the responsibilities and duties of their IT conversion.
Elements of the Project Leadership Structure
Before the project started, they negotiated across all levels of their company hierarchy, as well as with the corporate headquarters and IT group. They knew their company leaders and the IT professionals did not see eye-to-eye on the implementation details. They negotiated until all agreed on the project goals, requirements, relationships, and project plan arrangements. They planned how everyone would communicate. They set up conflict management protocols.
They made sure the project members surfaced their interpersonal and inter-group conflicts. Where possible, the staff resolved potential conflicts. Where they were not resolved, they at least managed them via the redesign of their project’s work process.
Two years later the insurance company project came in on time and on budget. It achieved its project goals. The new software was tested beside the old software for 12 months. When the switch to a new IT system went live, it was only after the professional staff was certain they had not lost or distorted any data in the transition.
The company’s top leaders did not give the go ahead to this project based upon whether it could benefit the company. They already knew only a successful implementation would make it a good and necessary business idea. For example, this innovative new software package would make their customer data base more valuable. Policyholder databases are a tangible asset in a life insurance company.
When the leaders were certain there would be a timely and complete implementation they gave their go ahead. They knew good ideas become assets only after they are functional.
Questions for Reflection:
What do you think are some elements of leadership structure that made this life insurance project successful?
In relation to scope creep, what actions have you seen that let you know in advance someone is pulling a project off course?
Watch for the follow-up article on Scope Creep: Good Ideas are not Assets