Assignment 1 Feedback
You have provided an excellent case study of a class project failure. You are correct in identifying the primary factors in the failure. Inexperience is something we are have suffered from at some point and therefore somewhat excusable, but when we are confronted with new challenges where we lack experience it is important that we seek out a more experienced advisor to help guide us through so our inexperience doesn’t harm the team. It is obvious this didn’t occur. This is a failure of the project manager but also whoever assigned this person to the role.
While the inexperience contributed to the lack of understanding of how to use resources, it also indicates a lack of understanding of the skills possessed by the team. That is not just a lack of inexperience but also a lack of curiosity and a disregard for the team’s individual and group expertise.
You definitely nailed the key to much of what went wrong when you identified the poor communications. The primary job of a Web Project Manager is to communicate status, issues, timelines, etc to the team, to stakeholders and to any sub-contractors, vendors or in this case the SMEs.
It sounds like this lack of communications may have then led to the scope of the project being expanded by the stakeholders (not surprising.)
It is the role of the Web Project Manager to ask the questions necessary to establish the requirements in combination with inputs from team members, document those requirements, communicate them to all stakeholders (including team members0 and get buy-in from everyone on the scope, timeline, cost and quality requirements.
Your example highlights this perfectly. Thank you for sharing such an appropriate case study.
Ah, churches are a special challenge to any Web PM. I was the Webmaster for our church for several years. When I became Director for Web Services for a university I watched my poor successor struggle with a site redo. He spent hours chasing cats trying to get approvals. After two years that site never launched and I took over the job again. I just launched the new site. One of the big obstacles with any church project is usually a committee must approve everything and there are many politics going on behind the scene that an outside design firm will have a hard time discovering and dealing with.
You correctly identify the main issue here – scope creep. We will be studying the importance of a
Change Policy and why this needs to be identified and approved as part of the initial contract. While this is always a concern with any client, it runs rampant with churches where some stakeholders will refuse to endorse a feature simply because another member is in favor of the feature.
Part of the change policy will state the charges for change requests and it is a good idea to include a Change Request Form in the Appendix of the Project Specification form. Get signed approvals of these documents and include and verbally explain charges that are the result of change requests before the project starts.
Be sure in your proposal to include a cost for testing the compatibility of any software you haven’t dealt with before and document a contingency plan if the software proves to be incompatible. This way you won’t get involved in the church debate over the special funds for cost overruns. Nothing can be as complicated as church finances and if possible, you don’t want to find yourself depending on a contingency fund the church has set up.
One issue that many people fail to appreciate with churches is that many times the minister is not the one in charge. We discuss high impact/high influence stakeholders in the class. In many denominations, the high impact/high influence stakeholder is not the minister, and yet the minister might well be the one that the account manager is dealing with when discussing the project. Dealing with churches it is best to meet and present to the Session or equivalent to learn who is the person who is really the one with the power and influence get consensus around project goals.
Just as the Web team needs a Web project manager to manage the project strategy, task list, development, content development, testing, maintenance, launch and closing, the church also needs someone who has the ability to resist the inevitable push for more and more change requests.
If there is no strong, knowledgeable and influential stakeholder in the church then it is often best to walk away from these opportunities as many times they end up a disaster for a design firm. A disaster than can harm a firm’s reputation and as your firm may have discovered, often result in a financial loss for the design firm.
Great case study and solid analysis.