Several years ago I was working on a software development team which produced a well-known 3D package. (I’ll leave the name anonymous, but it was used on several high-profile television shows and movies.) Much of the programming staff was excited when we got word that we were going to start a major new project that would allow us to create a new software package which would allow us to use next-generation tools and processes. Many meetings were held and an initial plan for the underlying architecture was created.
A few months into development the CEO of the company had another idea. He wanted to take the project public and invite customers to buy-in early to have access to the development process. In short, this was the beginning of the end for the project. A bungled, and publicly-panned, announcement of the project left a sour taste in the customer-base and caused some conflict between the development staff and management. Now the plan was being rushed in order to meet tighter deadlines. With the addition of a closed beta for those customers that paid, feature creep was more prevalent with more features that took development time from refining the essential underlying architecture of the software. With the loss of focus, the project started to go in multiple directions and the customers that were using the software were getting impatient with features not being fully-developed or not having their own ideas implemented. Van Rekom (Laureate, n.d.) states that scope creep always happens, so it must be considered when planning a project. I think we missed this critical step when we allowed so many new voices into the project.
Looking back, the project may have been more successful if more time had been given to developing a more stable architecture before others were able to influence how the software should work. Announcing a project and releasing the beta software before it was stable was also a tremendous mistake.
For my own part, as both an internal tester and technical writer, I contributed daily to bug reports and development of the user interface including documentation. While it was often difficult to keep track and stay up-to-date with ever-shifting software, I believe I was able to provide our customers with a usable set of documents that at least showed the basics of using the software that was released. Had the software development been more focused, I believe the end product would have been successful.
Laureate Education (Producer). (n.d.). Project management concerns: ‘Scope creep’ [Video file]. Retrieved from https://class.waldenu.edu