Case Study Creating A Methodology Background John Compton

Case Studycreating A Methodology1backgroundjohn Compton The President

Case Study creating A Methodology1 Background John Compton, The president of the company, expressed his feelings quite bluntly at the executive staff meeting; We are no longer competitive in the marketplace. Almost all of the Requests for Proposal (RFP) that we want to bid on have a requirement that we must identify in the proposal the project management methodology we will use on the contract should we be awarded the contract. We have no project management methodology. We have just a few templates we use based upon the PMBOK® Guide. All of our competitors have methodologies, but not us.

I have been asking for a methodology to be developed for more than a year now, and all I get are excuses. Some of you are obviously afraid that you might lose power and authority once the methodology is up and running. That may be true, but losing some power and authority is obviously better than losing your job. In six months I want to see a methodology in use on all projects or I will handle the situation myself. I simply cannot believe that my executive staff is afraid to develop a project management methodology.

Critical Issues

The executive staff knew this day was inevitable; they had to take the initiative in the implementation of a project management methodology. Last year, a consultant was brought in to conduct a morning three-hour session on the benefits of project management and the value of an enterprise project management methodology (EPM). As part of the session, the consultant explained that the time needed to develop and implement an EPM system can be shortened if the company has a 189 project management office (PMO) in place to take the lead role. The consultant also explained that whichever executive gets control of the PMO may become more powerful than other executives because he or she now controls all of the project management intellectual property.

The executive staff fully understood the implication of this and therefore became reluctant to visibly support project management until they could see how their organization would be affected. In the meantime, project management suffered. Reluctantly, a PMO was formed reporting to the chief information officer. The PMO was comprised of a handful of experienced project managers that could hopefully take the lead in the development of a methodology. The PMO concluded that there were five steps that had to be done initially.

After the five steps were done, the executive committee would receive a final briefing on what had been accomplished. The final briefing would be in addition to the monthly updates and progress reports. The PMO believed that getting executive support and signoffs in a timely manner would be difficult. The first step that needed to be done was the establishment of the number of life-cycle phases. Some people interviewed wanted ten to twelve life-cycle phases.

That meant that there would be ten to twelve gate review meetings and the project managers would spend a great deal of time preparing paperwork for the gate review meetings rather than managing the project. The decision was then made to have no more than six life-cycle phases. The second step was to decide whether the methodology should be designed around rigid policies and procedures or go the more informal route of using forms, guidelines, checklists, and templates. The PMO felt that project managers needed some degree of freedom in dealing with clients and therefore the more informal approach would work best. Also, clients were asking to have the methodology designed around the client’s business needs and the more informal approach would provide the flexibility to do this.

The third step was to see what could be salvaged from the existing templates and checklists. The company had a few templates and checklists but not all of the project managers used them. The decision was made to develop a standardized set of documents in accordance with the information in the PMBOK® Guide. The project managers could then select whatever forms, guidelines, templates, and checklists were appropriate for a particular project and client. The fourth step would be to develop a means for capturing best practices using the EPM system.

Clients were now requiring in their RFP that best practices on a project must be captured and shared with the client prior to the closeout of the project. Most of the people in the PMO believed that this could be done using forms or checklists at the final project debriefing meeting. The fifth step involved education and training. The project managers and functional organizations that would staff the projects would need to be trained in the use of the new methodology. The PMO believed that a one-day training program would suffice and the functional organizations could easily release their people for a one-day training session.

Questions

1. What can you determine about the corporate culture from the fact that they waited this long to consider the development of an EPM system?
2. Can a PMO accelerate the implementation process?
3. Is it acceptable for the PMO to report to the chief information officer or to someone else?
4. Why is it best to have six or fewer life-cycle phases in an EPM system?
5. Is it best to design an EPM system around flexible or inflexible elements? Generally, when first developing an EPM system, do companies prefer to use formality or informality in the design?
6. Should an EPM system have the capability of capturing best practices?

Sample Paper For Above instruction

The development and implementation of an enterprise project management (EPM) system within an organization reveal significant insights into its corporate culture, decision-making processes, and strategic priorities. Analyzing the case of John Compton’s organization offers a comprehensive understanding of how corporate culture influences project management practices and the importance of leadership commitment in fostering a culture conducive to systematic project management.

Corporate culture fundamentally shapes how an organization approaches change, innovation, and process improvement. In this case, the delay in developing a formal EPM system indicates a culture resistant to change or perhaps siloed decision-making. It suggests that there may be entrenched organizational norms where project management is viewed as an administrative burden rather than a strategic enabler. The reluctance to adopt a formalized methodology, despite evident market pressures and client requirements, underscores a potentially risk-averse or status quo-oriented culture. Such a culture may prioritize operational stability over strategic innovation, thereby hindering the organization’s competitiveness and growth prospects (Schein, 2010).

Resistance to change can be rooted in fears of loss of power, authority, or control, as evidenced by the executive staff's concern about losing influence when a new PMO is introduced. This behavior reflects a cultural attitude that perceives process improvements as threats rather than opportunities. Organizations with a hierarchical or politically sensitive culture often exhibit such resistance. Conversely, more adaptive cultures value continuous improvement and are open to adopting new methodologies to enhance organizational effectiveness (Denison, 2012). Therefore, the delay and hesitance suggest a predominantly conservative or risk-averse corporate culture that may hinder innovation.

The role of the Project Management Office (PMO) as a central organizational entity to accelerate the development and deployment of the EPM system is crucial. The PMO, composed of experienced project managers, is expected to lead the effort, develop templates, and facilitate training. While a PMO can significantly expedite implementation through standardized processes, templates, and best practices sharing, its success depends on organizational support and clarity of authority. A well-resourced, visibly supported PMO can serve as a change agent, fostering a project management culture aligned with organizational goals (Boehm & Turner, 2004). However, if the PMO reports to a functional or technical leader with limited influence, its effectiveness may be compromised, delaying progress.

Regarding reporting lines, it is generally acceptable for a PMO to report to the Chief Information Officer (CIO) if the organization’s strategic emphasis is on technology-driven project management. Alternatively, reporting directly to the CEO or a chief operating officer (COO) could elevate its strategic importance and ensure organizational buy-in. The decision hinges on the organization's strategic priorities and the PMO’s scope. Studies suggest that a direct reporting line to top leadership enhances authority, accountability, and the ability to effect change across functional boundaries (PMI, 2013).

Micro-managing the number of life-cycle phases in an EPM system is essential for balancing oversight and operational efficiency. Having no more than six phases facilitates manageable gate reviews, reduces administrative burden, and allows project managers to focus more on execution rather than extensive documentation (Kerzner, 2017). Excessively granular phases—such as ten to twelve—can lead to bureaucratic delays, resource drain, and diminished flexibility, ultimately impairing project agility. An optimal number of phases provides sufficient control without impeding responsiveness, aligning with best practices in project management (Wysocki, 2014).

The design philosophy of an EPM system regarding flexibility versus rigidity directly impacts its adoption and effectiveness. Generally, an initial informal approach—using templates, checklists, and guidelines—encourages user buy-in, adaptability, and customization to specific project and client needs. Formalized, inflexible procedures may discourage user engagement and stifle innovation. As organizations mature, they can progressively introduce more formalized processes, but early-stage systems benefit from flexibility and user control, fostering a culture of continuous improvement (Kerzner, 2017).

In terms of formality, companies developing their first EPM systems tend to favor informal design elements like checklists and templates to facilitate ease of use, quick deployment, and acceptance among project staff. Informality reduces resistance, accelerates training, and allows tailoring to diverse project contexts (Heldman, 2018). Over time, as experience and organizational maturity grow, formalizing processes ensures consistency, compliance, and knowledge capture—including best practices—which are essential for long-term success (PMI, 2013).

Finally, the capability of an EPM system to capture best practices is paramount. Embedding lessons learned, successful strategies, and process improvements into the system promotes organizational learning and continuous enhancement. Capturing best practices enhances project outcomes, reduces rework, and accelerates knowledge transfer among teams (Kerzner, 2017). Incorporating mechanisms such as lessons learned repositories, debrief checklists, and knowledge management tools ensures that valuable insights are retained and leveraged in future projects, thereby strengthening the organization’s project management maturity (Lientz & Rea, 2014).

References

• Boehm, B., & Turner, R. (2004). Balancing agility and discipline: A guide for the perplexed. Addison-Wesley.
• Denison, D. R. (2012). Corporate culture and organizational effectiveness. John Wiley & Sons.
• Heldman, K. (2018). Project management jumpstart. Wiley.
• Kerzner, H. (2017). Project management: A systems approach to planning, scheduling, and controlling. Wiley.
• Lientz, B. P., & Rea, K. P. (2014). Project management for the frontline manager. Academic Press.
• PMI (Project Management Institute). (2013). A guide to the project management body of knowledge (PMBOK® Guide). PMI.
• Schein, E. H. (2010). Organizational culture and leadership. Jossey-Bass.
• Wysocki, R. K. (2014). Effective project management: Traditional, agile, extreme. Wiley.