Over the last few weeks, I have learned a great deal about
project management and its perils. One
such peril is scope creep. I wasn’t
aware of that term until just recently, but I believe that it is one of the
most important terms I have learned in a long while! My experience with scope creep resulted from
my own enthusiasm for a project and for wanting to do the best, most amazing
and spectacular job that I could. The
“client” was a joint state and federal grant program for the creation of open
source curriculum. The requirements were
rather simple and three years seemed like such a long time.
I was not the project manager, but rather a team member
responsible for developing and creating curriculum in my subject area. To be truthful, there was no project manager
and I believe that this is what contributed to the problem most of all. Without that single point of control, that
single point of grounding in reality, I was able to go beyond what was expected
without regard to cost or time.
The response to my spectacular offerings (and they really
were spectacular!) was very good! Rather
than having a project manager to put on the brakes, I went full steam ahead
with the encouragement of the stakeholders.
They had no idea of the amount of time and effort that these modules
consumed, however. I continued to work
on this project until I realized that I had spent several months working on
only a small part of a huge project! The
reality was that each module should have had days allotted, not weeks and
months. I panicked when I realized that
I had lost a huge amount of time going beyond the requirements. I spoke to my manager, scaled back my efforts
to meet the grant requirements, and tried to catch up to the next milestone.
While I may not have met the unrealistic expectations that I
created for the stakeholders, I did manage to fulfill the requirements of the
grant on schedule. I also learned some
valuable lessons.
Portney, et al. (2008) discuss the need to manage scope
creep by requiring a process be followed before any change is made to the
scope. All changes must be approved and
the schedule must be adjusted as necessary to allow for the changes. By managing scope, schedule, budget,
expectations, and risk, the project manager can control scope creep (Lynch
& Roecker, 2007).
The most important lesson that came from that project is
that somebody has to be the project manager.
There must be somebody who is keeping track and making sure that the
project stays on course and doesn’t explode into a bigger project. Or implode and fail. I think that my near misses and failures of
the past will come in handy if I am ever in a position to manage a
project. While project management has
some aspects that can be learned in books and in seminars, I think the most
important lessons are learned on the job in each success and misstep made along
the way.
References
Lynch, M. R. (2007). Project managing e-learning: A
handbook for successful design, delivery, and management. London:
Routledge.
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.
There were a few lessons in your example. One is keeping adequate communication between team members to prevent what you experienced. Another is to properly define roles, the most important being the project manager to keep the team focused and grounded. Next is that scope creep isn’t necessarily due to bad luck or poorly handled tasks but can come from motivated, well-intentioned members of the team. This one stood out to me the most. I previously thought that scope creep was an intentional act of someone trying to get more out of a project than what they had originally negotiated (or pay less or do less work).
ReplyDeleteThe best news is that you learned these lessons and are now well-armed to lead teams to success without confusion or frustration.