 |
| youngentrepreneur.com |
As a programmer, I encountered scope creep in the form of program changes that really should have been handled as new projects, but were instead added to current or recently completed projects. As with most projects, a programming project has defined users and a defined environment in which the software will be used. Assumptions are made about the equipment that will be operating the software. Assumptions are made about the kind of data that will need to be stored, and whether that data will be stored locally, or on a network.
One extreme example of a programming project that was negatively impacted by scope change began as an unofficial proof of concept program by an engineer who felt software could be written that would save time by assembling a PLC program from a list of standard operations. The initial proof-of-concept was written to program one test machine that was not actually connected to any equipment. The program allowed an engineer to select from a group of pre-defined sets of instructions to create a program to operate automated heavy machinery. Then it read back the program to demonstrate the instructions were sent properly. Next the program was altered so that it could store its instruction sequences to a program file on a laptop. When I thought the project was complete, I was suddenly confronted with several requests that pushed the capabilities of the original test design. Engineers wanted to be able to connect to a variety of machines, including completely different kinds of machines that stored information in different ways. New subroutines had to be written for each kind of machine that the program would interact with.
Some engineers wanted to use the program for troubleshooting a PLC that was off the network. They wanted to be able to connect to PLC’s directly or over the network. Then they wanted security protocols added so that all engineers could see the program code on the PLC, but only certain engineers could alter programs and change them. After network security protocols were added, they wanted to have the same capability whether the computer was connected via the network or when connected directly to the PLC.
Other departments began using the program. Suddenly slow operation of the program (that was designed to test a concept, not to actually run in a production environment) was identified as a cause of production delays. With many more people using the program, there were demands to override security by people who may or may not have understood the safety issues involved in using the program. Meanwhile other departments were demanding to use the program to read parameters from a spec database to standardize machine setups and eliminate the step of having engineers write the PLC programs.
Finally it became necessary to stop all changes to the old program. A new programming project was properly designed to replace the old program, which eliminated many of the conflicting uses of the old program, such as the ability to run on the network and from a laptop. The old program was retained for its ability to display existing programs, but it was no longer used to write and store new PLC programs.
In hindsight, the prototype program should never have been put into use in a production setting. At that point, a new project should have begun, involving all departments that would be using the program, to insure safety and to ensure performance demands for all possible users and environments for the program were considered and planned from the beginning.
References:
Portny, S. E., Mantel, S. J., Meredith, J. R., Shafer, S. M., Sutton, M. M., & Kramer, B. E. (2008). Tracking projects and maintaining control. In Project management: Planning, scheduling, and controlling projects. Hoboken , NJ John Wiley & Sons, Inc.
David,
ReplyDeleteWow! This sounds like scope creep on steroids. What a nightmare. Your example of the Swiss army knife with 10,000 blades was perfect for portraying this project. The article was right on also. Zwilling (2010), in talking about scope creep, stated that adding on just a few more things results in a bloated first product which finally collapses under its own weight, or is too late and too expensive for the intended customer. This sounds exactly like what happened with this project. Like you said, it was a prototype and never meant to be used in production. Whoever allowed this to get so far out of control must have not understood the "NO". Someone needs to buy him a rubber stamp.
Zwilling, M. (2010, December 27). Leading edge becomes bleeding edge with feature creep. Retrieved 2/12/2011 from http://www.youngentrepreneur.com/blog/leading-edge-becomes-bleeding-edge-with-feature-creep/
Hi David,
ReplyDeleteIt appears there were many elements of the instructional design and project management missing. As I was reading, I had a hard time finding a purpose for the project, other than adding to a previous program. The loss of proper planning with objectives, the lack of focus, absence of authority, responsibility, and accountability were also missing. The schedule of activities was especially week. In our text "Project Management-planning,scheduling, and controlling" the importance of these actions is repeated and advised. "Early on, project teams need to establish team and individuals goals for the project as well as team roles and responsibilities" (Portney,Mantel, Meredith,Shafer, Sutton, Kramer,2008) This quote does stess early on, and goals for the project and not in addition to an old project. Putting the prototype into the production should never have happened because it left the result to a hit and miss situation with probably an insurmountable amount of criticism.
Portny, S.E., Mantel,S.J., Meredith, J.R., Shafer,S.M., Sutton, M.M. & Kramer (2008) Project Management-planning, scheduling, and controlling Hoboken, NJ: Pearson Publishing
David -
ReplyDeleteThis sounds like a very bad case of scope creep! Using a program for something other than it's original design can have some very big implications to business. It sounds like having a clear definition of the original project and requirements could have helped as additional requests were made. A scope change document or change board process (Portny et al, 2008) could have helped manage all the requests from different departments and users. It also sounds as if the project become a victim of "the unknown" and "acquisition", two titles Brenner gives in his article "Some Causes of Scope Creep" (2002). The unknown part comes from not knowing the complexity and intricacies of project and the acquisition comes from different areas wanting to use your product, even though it was not intended for them.
It is sad that sometimes a good project, or program in your case, can get lost in the shuffle when it becomes used for purposes other than what it was designed for.
Brenner, Rick. “Some Causes of Scope Creep.” Point Outlook. September 4, 2002: Volume 2, Issue 36. Retrieved February 13, 2011 from http://www.chacocanyon.com/pointlookout/020904.shtml
Portny, S. E., Mantel, S. J., Meredith, J. R., Shafer, S. M., Sutton, M. M., & Kramer, B. E. (2008). Project management: Planning, scheduling, and controlling projects. Hoboken, NJ: John Wiley & Sons, Inc.