Years ago in what
seems like another life, I worked as a software engineer on an engineering team
for a small family-owned corporation.
There was no official PM, so the Director of Engineering assumed that
role. The core business was
manufacturing time clocks, although the time and attendance software which was
developed for a specific line of clocks was a rapidly growing part of the
company. The executive team, (C.E.O.,
director of marketing, director of engineering, vice president of
manufacturing, and purchasing agent) would work together on the high-level
requirements of the project. The
director of engineering would then bring the requirements to our team to gather
information, ask additional questions, mock up a user interface for the
software and give initial feedback to the marketing team. The screen shots provided would either be approved
or tweaked based on their understanding of the user’s requests. The project would progress through the
software development life cycle before a new release was actually burned to
CDs.
The company I worked
for did not have a “formal post-mortem” process. By that I mean there was no report, no
comprehensive notes taken along the way to review at the end, or team
reflection. Instead, we discussed loosely what gotchas came up during testing
such as the release of a new operating system which in those days was either
16-bit or 32-bit platforms, third party dynamic link libraries which were
incompatible with a specific operating system, etc. So were we proud of the finished
deliverables? In all cases we were,
because end-users were often able to beta test the software before the full
release.
Scope creep was the
most frustrating part of our project. In
a small company, the inevitable, “just one more feature” was guaranteed. Unfortunately, that feature would be larger
than the scope of the original project and would add on weeks if not months to
the release date of the software. Dr.
Stolovich says, "Let the client know that their additional
ideas and wants are very valuable, but let’s finish the project that’s been
spec’d and revise that once its tested and acceptable to add additional
features or to meet another need.” (Stolovich, n.d.)
Although the
director of engineering would be as firm as he could about sticking to the
original project request, it was often negated by the C.E.O. who felt that
feature could increase sales of the product.
It’s kind of hard to say, “Next version” to the person whose name is on
your check. What worked well for a short
time was the relocation of the entire engineering department to a separate
location. The day to day interruptions
from marketing team members drifting in for informal reviews, manufacturing
supervisors asking for test software changes to accommodate the electrical
engineer’s new firmware, etc. were curtailed by the physical separation of the
department. The distance of the
developers from the rest of the plant, ensured more focused time, but the
culture of the company supported scope creep.
The customer was the most valued stakeholder and delivering a product
later with their request incorporated outweighed any padding of the development
timeline.
References:
Stolovich,
H. (Producer). (n.d.)Project Management
Concerns: ‘Scope Creep’. Laureate Education, Inc. Retrieved from
https://class.waldenu.edu/webapps/portal/frameset.jsp?tab_tab_group_id=_2_1&url=%2Fwebapps%2Fblackboard%2Fexecute%2Flauncher%3Ftype%3DCourse%26id%3D_1373695_1%26url%3D
Carol,
ReplyDeleteI would agree that certain company cultures lend themselves to scope creep. I heard complaints all the time from the IT and Marketing departments at the last company I worked for because people would enter their space with their ideas - it was especially difficult when managers would come in wanting to have changes made. It's interesting that your company recognized that and made location adjustments.
As a PM I find Stolovich's words to be best followed; when ideas are generated and changes wished for that are outside the bounds of the scope, allocate them to an entirely new project. After all there is an iron triangle and no matter how hard people like me try to accommodate it's best to say no.
The PM must take an active role in reigning in SME's, managers, stakeholders and project team members and keeping the project focused (Murphy, 1994).
Johanna
Murphy, C. (1994). Utilizing project management techniques in the design of instructional materials. Performance & Instruction, 33(3), 9–11.
Johanna,
DeleteThanks for your response. I would assume that not every “idea” which is generated and slated for a future project is actually adopted. Do you follow-up or find that difficult to deal with?
Hi Carol:
ReplyDeleteMy projects occasionally fall victim to the boss creating the scope creep in order to satisfy a client, usually an internal client. With a new director at the helm he understands the need for planning and maintaining that plan. When he requests a change to that plan he wants to know how it is going to impact the final outcome. Though he has the final decision, he does listen to the PM. Portny et al. illustrate a change control system and how it should be employed when there is a change requested to the project. When a change is requested, it is analyzed and determined how the request will impact the project. The advantages and disadvantages are considered along with any alternatives. If the change is authorized it is then communicated to all necessary individuals and to make sure the changes are implemented. A summary is created and added to the project documentation (2008).
It looks as if your company made attempts to limit scope creep by put some space between departments. This does dissuade the impromptu meetings that may contribute to scope creep, but it the culture of the company fosters it consciously or not, it is still going to be an issue. Only by sticking to the agreed upon plan can essentially limit scope creep to all but the absolute necessary items. Scope creep is not inherently bad; it may provide necessary items that were not included in the original plan. If it is left unchecked it can truly sink the best-planned projects.
Thanks for sharing,
Brad
Reference:
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, N.J.: Wiley.
Carol,
ReplyDeleteThere is something about a small family-owned operation that makes it qualitatively different from other enterprises. I believe it may have something to do with the owner’s entrepreneurial vision and personal aspirations for self-actualization or perpetuation of a familial legacy or lineage. It could also be that they view their unorthodox actions as a way of defining the most salient characteristic of catering to a niche market and/or differentiating their company from its competitors. But for whatever reason, the result seems to be a leadership style that assumes a broader role than that outlined by Portny (et. al., 2008) where upper management “…creates the organizational environment; oversees the development and use of operating policies, procedures, and practices; and funds and encourages the development of information systems” (p. 12).
By creating a culture that supported scope-creep, the owner-manager in your project post-mortem “flipped the script” on the traditional PM role of developing a plan that organizes a project team to perform the required tasks to achieve the desired results in the prescribed period of time with the available resources (Portny, et. al., 2008, p. 377). Instead, he was apparently driven by the belief that by guaranteeing customer satisfaction, there was a reasonable chance that increased sales could deliver a reasonable ROI, and that the investment was worth the potential risks associated with the increased cost.
Portny (et. al., 2008) defined risk as “…the possibility that a project might not achieve its product, schedule or resource targets because something unexpected occurs or something planned does not” (p. 377). But since the inevitable, “just one more feature” was also guaranteed; the main preparation for risk by the project manager (or Director of Engineering) should be the development and maintenance of a Risk Management Plan (p. 393). Given the high probability of the occurrence of scope creep, the PM should consciously invest more time and effort in identifying and budgeting unanticipated project costs during the conceive phase, and more fully “fleshing out” that infamous “just one more feature” during the design phase.
Another critical risk management strategy that should be implemented by the PM is the complete documentation of any changes to the project agreed to by the CEO on a Scope Creep Document which should include the anticipated additional cost. This document should be incorporated into a formal process that requires signatures and approvals by the major stakeholders. Stolovitch (Laureate, 2010) recommended that, if the client wants to add more work to the project, then the Scope Creep Document should clearly reflect the allocation of any additional resources such as time, money, manpower, and equipment. In addition, I think there should also be a way to capture and document the “opportunity cost” associated with tying up resources that might otherwise be involved with other revenue generating or value adding activities.
So, given the organizational culture supporting scope creep at this family-owned corporation, I see the essential role of the Director of Engineering /Project Manager shifting from that of strictly adhering to a project plan or to the original project request, to that of generating the data and communicating the necessary information to the CEO that could be used to more accurately quantify the actual ROI and justify his decision-making processes.
References:
Laureate Education, Inc. (Producer). (2010). Project management concerns: Scope creep [Video program]. Baltimore, MD: Solution Tree.
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, N.J.: Wiley.