EDUC-6145 – Analyzing Scope Creep

“Input from more than 500 project managers regarding the most important single problem facing project managers indicates that coping with change is at the top of their list.” (Portny, 2008, p. 346) Further, “scope creep refers to the uncontrolled changes in the requirement [of the project] as defined in the scope definition of the project management plan” (Lynch, 2007, p. 96). As a technical lead and sometimes project manager on software development and implementation projects for more than 20 years, I have come to understand that scope creep is inevitable and have learned that efforts to manage scope creep are far more useful than efforts to prevent it.

For this week’s blog assignment, we are to describe a project, either personal or professional, that experienced issues related to scope creep. The project I’d like to discuss is a small one I’ve been working on for the past two months. The project came about in response to a need to be able to render batches of Physician Profile reports on a schedule, and without using the data driven subscriptions functionality that comes with SQL Server Management Studio (SSMS). The Physician Profile reports are part of a Performance Initiative that customers buy for ~$20K to track all manner of metrics about physician performance. The reports are parametrized and because of this, the only way to automate their rendering is to use the data driven subscriptions; however, data driven subscriptions requires SQL Server Enterprise Edition, which can cost upwards of $30K for a hospital, depending on their licensing needs.

I was initially tasked with finding another way to render the reports without using data driven subscriptions. I found a solution within 48 hours, wrote up the details of what would be required to make it happen, and fully expected that a project to implement the solution would be established. It wasn’t. I was next tasked with providing a proof of concept showing how the solution would work. A couple of weeks later, I had a working model, which I demonstrated and documented, again expecting that a formal project to implement would result. It did not. I was next tasked with developing a model that could be installed and demonstrated at a customer site. A couple of weeks later I had a fully functioning system, and by this time, the solution had grown quite substantial. Not only did the solution provide the means to render the Physician Profile reports in batch and without using data driven subscriptions, the reports could be scheduled to run automatically, the could reside on any server or distributed across multiple servers within the hospital network, the solution could be initiated and managed from a web page and where the rendered reports could also be queued for printing. There was also functionality added in to accommodate some unknowns about customer usage needs.

In some ways, this project was a technical developer’s dream come true. I started from nothing and made something quite substantial, and I was given carte-blanch in terms of freedom in technical design. I was also completely free from any demands of project schedule deadlines. On the other side of the coin, I was given very little information about the actual requirements of the customer.

From a project manager’s perspective, this project was very poorly managed (it actually wasn’t managed at all). Instead of an official project plan, I was flying by the seat of the pants of the person asking for the solution. As a competent and knowledgeable product specialist, she wanted to provide the customer with an alternative to SQL Server Enterprise Edition, but as a project manager, she had absolutely no sense of what it would take to develop or implement the alternative solution. Neither did she have the ability to understand the implications of what she was asking for, even when clearly explained. She wanted what she wanted, full stop.

Had I had the advantage of managing a project plan for this project, I would have developed the proof of concept using a development partner (a hospital willing be a test bed) so that actual customer usage needs would be known at the start and all that added functionality would have been avoided. I would have phased the development so that much of the functionality that ended up in the final product would have been added on in phases, and even sold as add-ons or upgrades, allowing the base product to get to GA (General Availability) months sooner and providing the company with opportunity for added income from the upgrades. And above all, I would have had change control procedures in place so that  there was an appropriate avenue to deal with every request that fell outside the scope of the project. Portny, et al (2008) advise us to anticipate changes at the beginning of a project, and that “the best practice for dealing with…change is to include a formal change control procedure in the contract” (p. 140)

References

Lynch, M. M., & Roecker, J. (2007). Project managing e-learning: A handbook for successful design, delivery, and management. London: Routledge. Copyright by Taylor & Francis Group, LLC. Reprinted by permission of Taylor & Francis Group, LLC via the Copyright Clearance Center.

Portny, S. E., Mantel, S. J., Meredith, J. R., Shafer, S. M., Sutton, M. M., & Kramer, B. E. (2008). Budgeting Projects: Planning and estimating project costs. In Project Management: Planning, scheduling, and controlling projects (pp. 117-147). Hoboken, NJ: John Wiley & Sons, Inc.