Here’s how I managed Scope Creep as a professional project manager.
The story was collected from an interview of us with Amr Kassem, a professional IT project manager, who started out as a developer (ITWorx INC.), moving on the Business Analysis area (in SunLife Financial and Underwriters Laborities), and finally working in the Project Management area of the industry.
Interviewer:
Every managers have their own issues in managing a project. But there will always be the worst one. So, what was the project that exhausted you most?
Amr Kassem:
In a few words, scope creep.
Was working on a year-long project. It was one of those big, ginormous projects with not only the software implementation, but also reports, data migrations, integrations and, in addition to all that, software enhancements to our platform.
Allow me to give you some background, my company sells software to our clients based on a locally developed configurable platform. A typical implementation is one that implements a module or 2, based on off-the-shelf modules where the team applies the client’s configurations and we are ready to move forward.
In this case, the platform was brand new, this was the first client who was touted as a beta partner, we were implementing 5 modules (a typical implementation has 1–2), and, major code enhancements were going to be required to enhance the platform to allow us to configure the modules correctly for the client.
The challenge was not managing all these streams though. The client manager was the issue. At the time, this was one of the biggest projects my company had ever undertaken, and the account manager wanted to please the client and reward them for signing up to be the first try out our new software.
Every time he met with the client, a new requirement would pop-up.
No matter how many meetings we had to assess risk, emphasize how tight our schedule is, and how we can’t take any more additions, a new requirement would pop-up the following week and he would:
1. Run around me to tell the team directly what is needed
2. Come tell me that this was a functionality planned all along, and we just need it
To put a stop to the frenzy, I made sure I was always on client meetings, to be able to manage expectations first-hand. In addition, I escalated the project internally to the client director. Once they got involved, and were routinely on client meetings. More importantly, I sat down, and had to learn 5 new business models (the 5 modules we were implementing) so I could tell when something was an original functionality, or was made-up to please the client.
With the combined effort of all these, the frenzy calmed down and things became manageable again.
Interviewer:
What was the critical issue you found behind the story above? Did you use Agile Methodology to cover such issue?
Amr Kassem:
The challenge with the project above was simple, when you try to express it in the Agile methodology; it was simply non-existent.
The team worked in a frantic mode, lead by an account manager who refused to listen to any other opinions because he’s ‘… been doing this for 12 years already…’.
For example, platform code builds were requested on the fly; a week could pass where we could take 2–3 builds because the feature was not documented correctly or there was a gap because proper analysis had not been done.
To cover these issues, I stepped in to formulate a process consisting of a big analysis phase in the beginning. This process lead to the team being split into several streams, each working in isolation (having them interact would have led to the frenzy mode again, so I had to be the main bridge for communication, which put additional strain on me). We had:
1. Analysis sprints — lead by the business team with the goal of:
- Developing requirements for new functionality required for the project
- A delivery plan, for the order and priority these features should be delivered to the client
2. Development sprints — where developers & QA team would code, test and remediate on the feature being developed/testing during this sprint
3. Configuration sprints — where configuration analysis would configure portions of the application
Managing these in unison, allowed the project cadence to be much more comfortable for the whole team and for the whole solution to come together in the end.
The story above relates to one of the most popular issues in managing a project these days. What do you think about the story? Share your thoughts below and contact us if you want to contribute your own experience to everybody in this community.
Sharing is learning. “The happiest people are those who are contributing to the society” — Ted Turner.
