Reflection on Project
Management – Post Mortem
I
have not always been a secondary education social studies instructor. In the middle of my teaching career, I will
decide to attend a local community college and receive my networking degree and
become a nationally certified IT technician.
My love of computers and technology is just as strong as my love of
teaching, and I was ready for a change.
A local software company that specializes in military software will hire
me as a network administrator. In the
first few months of the new job, the owner of the company will ask me to lead
the project to build a new and interactive educational website for our local
office for students and others to use as an educational resource.
Dr.
Stolovich in his instructional video goes into explaining that a good project will
contain a thought out scope or Work Breakdown Structure (WBS). Every part of the project and the assignments
need to show before a project takes off (Stolovich, 2012). I never did a lead on a technology project
that was going to be quite so vast and require details for the website. Our book describes items such as Statement of
Work (SOW) that helps lay out an outline and timeline of a project. I did perform some of these items in a SOW
such as the purpose and objectives, but it is never put into a formal statement
for approval (Portny, Mantel, Meredith, Shafer, & Sutton, 2008). The project began with a good start, and
weekly meetings on Monday afternoons took place. I broke the project into three groups of education,
content, and design. The project did
contain all fifteen staff members from our regional office and also the
president of the company who resides in San Francisco, California. From the beginning, I will experience “scope
creep” from the president of the company.
She will keep adding more and more items she wants inside the website
and project. After a few weeks, the
project is a monster and my timeline and groups begin to lose focus on
tasks. Scope creep as we know is a significant
problem for any project and is sometimes may cause the demise or slowing a
project (Van Rekom, 2012). Ultimately
the project became so complex and it never sees completion. Why did this
project fail? What could be done differently to make it successful?
The
failure of this project is because of two reasons: a lack of organization on my part and scope
creep in regards to the president of the company. A more specific plan and organization from
the beginning of my project are something I now see as my first pitfall. The idea of creating a SMART plan in which I
lay out the five objectives (Specific, Measurable, Aggressive, Realistic, and
Time Sensitive) is one way to achieve this project’s success (Portny, Mantel,
Meredith, Shafer, & Sutton, 2008). My
lack of specific target dates, a statement of work, and a work breakdown
structure are the three areas where my lack of organizational skills is
obvious. The project boundaries are not
obvious and lead into the second issue of why this project’s success does not
happen (Portny, Mantel, Meredith, Shafer, & Sutton, 2008). Stolovich says it is sometimes acceptable to
tell a client “no”, but it is a difficult challenge when it is the president of
the company (2012). The approach I need
in this situation is to conduct a private meeting with the president of the
company and discuss adding these items into a second version of the
website. The 2.0 version of this project
is where these additions need to take place.
Official signatures on this project from upper level management are a good
way to make this project a success.
This project is one I will never
forget because it is still in a state of limbo and the remnants remain on my
computer today. In just the short amount
of time in this course, I see the importance of organization, deadlines,
signatures, and details. Scope creep and
lack of organizational skills are two deadly sins that can destroy a project
quickly and lead to a frustration on the part of the project manager, team
members, and management. I will take
this lesson with me into the future and learn from my mistakes. The posting of this story is a valuable
lesson for anyone who desires to become a project manager.
References
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.
Stolovich.
(2012). "Defining
the Scope of an ID Project".
Retrieved on January 12, 2012 from
Stolovich.
(2012). "Project Management
Concerns: ‘Scope Creep’”. Retrieved on
January 12,
Van
Rekom. (2012). "Practitioner
Voices: Overcoming 'Scope Creep’".
Retrieved on January
Hi Eric,
ReplyDeleteSo it seems that your project example is not such a rarity in the technology arena. Research suggests that Software projects are infamously problematic, difficult to manage and often end in failure. Annual spending in 1995 on U.S software projects reached nearly $250 billion for an estimated 175,000 projects. Despite the risk and cost involved projects are incurring significant expense at an estimated $59 billion in project overages and whopping $81 billion in cancelled software projects (Keil, Cule, Lyytinen, & Schmidt, 1998).
Managing scope creep is the project managers’ job from day one. Some of the ways to do this is to ensure you thoroughly understand the project vision, break the project down into major and minor components with approval check points, and align project deliverables to work requirements, employ Change Order forms from the beginning, inform project drivers of the processes (Doll, 2001) and create a Work Breakdown Structure or RASCI. The RASCI will provide details on the projects responsible people, approvers, support people, consultants and the people who should be informed (Stolovich, 2012).
I believe there is always a lesson in an unsuccessful project. Effective project managers need to be able to anticipate outcomes. They should not restrict their attention to risk associated with the project but also consider if they are committed and have the support to successfully complete the project, be able to manage uncertainty and change associated with the project scope, and be able to efficiently anticipate and respond to changes in the environment (Keil, Cule, Lyytinen, & Schmidt, 1998).
References
Doll, S. (2001, March 31). Seven steps for avoiding scope creep. TechRepublic - A Resource for IT Professionals. Retrieved January 19, 2013, from http://www.techrepublic.com/article/seven-steps-for-avoiding-scope-creep/1045555
Keil, M., Cule, P., Lyytinen, K., & Schmidt, R. (1998). A Framework for Identifying Software Project Risk. COMMUNICATIONS OF THE ACM, 41(11), 76-83. Retrieved from ftp://163.25.117.117/gyliao/PaperCollection/20091206/A%20Framework%20Identifying%20Software%20Project%20Risk.pdf
Stolovich. (2012). “Project Management Concerns: ‘Scope Creep’”. Retrieved on January 19,
2013 from https://class.waldenu.edu/webapps/portal/frameset.jsp?tab_tab_group_id=_2_1&url=%2Fwebapps%2Fblackboard%2Fexecute%2Flauncher%3Ftype%3DCourse%26id%3D_2097260_1%26url%3D
Eric,
ReplyDeleteThe ideas to try and better this project seem like they could have made a difference in the outcome. You mentioned that you didn't really set clear deadlines to the various parts of the project, Greer (2010) discusses looking at effort, duration, and resources before considering a schedule. Greer makes sure to discuss the difference between duration and effort and how this can greatly impact the completion of a project being on time. Effort would be the number of hours required to complete the work by the team member while duration is the total amount of time needed to complete the task. I really like the analogy that Greer used when he compared the process to building a sidewalk; effort would be the number of hours it would take the workers to dig out the old cement and lay the new cement while the duration includes that time plus the time it takes for the cement to dry. I don't think I would have thought about the two as being different until I read this article. I think this differentiation between duration and effort could help many project managers complete tasks on time. To help project managers I would suggest making an effort/duration table prior to creating a schedule. I think the effort/duration table will help the project manager plan for obstacles and difficulties that could be potential problems down the line, helping to ensure the completion of a project on time.
Scope creep can be a major challenge when leading a team through a project because you want to believe that you can take on all of the items the client is asking, but is generally not possible. I like the idea you shared about meeting with the client privately to discuss future projects and how their ideas would fit better there. I think this situation will allow the client to be heard and respected and have a conversation with you to hear your reasonings.
Reference
Greer, M. (2010). The project management minimalist: Just enough PM to rock your projects! (Laureate custom ed.). Baltimore: Laureate Education, Inc.
Eric,
ReplyDeleteThat was a great, real-life example. Just starting out in the field will be hard enough, and of course, you want to make clients happy by saying yes to additional jobs to be performed. I was looking up articles and ran across the same one Sharifa cited, by Doll. The seventh step was basically to know that it's going to happen and expect it. It must be dealt with by using a change order to help determine any cost and scheduling changes (Doll, 2001). Your suggestion to have a private meeting with the president to review the information would probably accomplish the same thing. I think this is where all of the upfront paperwork comes into play, like the Statement of Work. I think having it on paper as a guideline may help project managers stick with the plan, however, at the same time we still must be prepared to modify and make changes if needed.
Doll, S. (2001, March 31). Seven steps for avoiding scope creep. TechRepublic - A Resource for IT Professionals. Retrieved January 20, 2013, from http://www.techrepublic.com/article/seven-steps-for-avoiding-scope-creep/1045555
Eric,
ReplyDeleteI think that you are right on track with your reflection of what went wrong with this project. Weigers, 2000 talks about 10 traps to avoid on a project; one of which is scope creep. Although not uncommon, Weigers recommends ensuring that the scope is defined appropriately and agreed to from the beginning and that an established change control process exists. He also mentions that some degree of scope creep is to be expected and plans should include a buffer to accommodate what he calls a natural evolution.
Reference:
Wiegers, K. E. (2000). Karl Wiegers describes 10 requirements traps to avoid. Software Testing & Quality Engineering, 2(1).