I’ve always wondered what it would be like if companies suddenly stopped hiring project managers. Would more projects fail? Would there be more chaos and confusion? Would developers or development managers make better project managers or be able/willing to fulfill that role? Are project management roles transforming into scrum master roles or a hybrid of both project manager and scrum master? Are projects completed more quickly with project management involvement?
Today, let’s discuss whether companies still need project managers, and, if so, what this role should look like.
There are a lot of questions and debate over the future of PMO and many opinions regarding what the PMO should look like. Some believe that having a centralized PMO is a necessity in an organization that needs enforcement of compliance and process standardization. Others believe that these roles should focus on results and delivery, the priority being to get the work done with minimal energy spent on processes and compliance. Based on my experience, I suspect the answer may lie somewhere between these opinions. More importantly, the PMO role depends on the culture and politics of the organization.
Just recently, I heard of a large e-commerce retailer in San Francisco that just did away with the PMO organization. I was saddened to hear the news about the cuts because I’ve worked with so many good people in that organization. Having seen a trend in that company’s push towards getting things done and minimizing bureaucracy, however, I was not surprised by the sudden cuts, but I was intrigued by how leadership came to determine that it might be good to decentralize the PMO and the benefits it brings.
I believe that a PMO organization that does not re-define itself will give a diminishing return to the company and will end up with a perception problem, trying to justify its relevance within the organization. When a company has a PMO organization staffed with program/project managers, the question is about their value proposition. What do program/project managers do to provide value to the organization?
Let’s first look at the traditional definition of project management. According to Wikipedia, "project management is the practice of initiating, planning, executing, controlling, and closing the work of a team to achieve specific goals and meet specific success criteria at the specified time." While this definition holds true to the project management role and responsibilities, it may no longer be a relevant way to deliver projects quickly and iteratively.
Traditionally, project managers oversee project progress and deliverables, call out issues and risks, provide status reports to senior leadership, and manage the project through its lifecycle. They may also manage budgets and be the “gatekeeper” to ensure that each phase of the project meets its objectives. This is WHAT project managers do, but HOW they do the work is often where the value of a project manager is realized.
As organizations are breaking down and flattening hierarchy structures, team-based decision making and ownership may be becoming the new norm. Perhaps combining the role of a traditional project manager and scrum master will provide the PMO more latitude and direct engagement with the project team, all while ensuring adherence to any compliance and process standards that are required by the organization. The role should be more about being an advocate and supporter for the team and involve only minimal effort in enforcing standards and processes that are mandated by law.
(For example, SOX [Sarbanes-Oxley] compliance is imposed by the government for corporate governance and accountability, and audits are conducted annually, so it is in the best interest of companies to comply. Anything to do with funding or sharing any customer information also needs to be managed carefully since it is tied to the PCI/SOX compliance governance.)
As I mentioned earlier, as organizations are heading toward a more iterative and shared responsibility by the project team, the PMO will have to reinvent itself to stay relevant. Whether the PMO is the repository for processes, standards, or compliance, the perception is that project managers may be the cause of slowing things down (intentionally or not), or worse, of being a large overhead cost to the company’s development budget.
Image courtesy of KeepInspiring.Me
Looking at PMOs as change agents rather than managers overseeing gating checkpoints, reporting statuses, or managing budgets means a radical shift in the type of role hired to fulfill a client's needs. The new ideal for a project manager is someone who has many years of project management/scrum master experience and has successfully delivered initiatives in an Agile environment while still navigating through processes and compliance requirements.
Perhaps the new PMO mission statement would be to reassess and streamline processes, reduce or eliminate documentation, limit the length and number of meetings, and do away with constant status updates, instead focusing on making things easier and more efficient for the development team without jeopardizing any SOX compliance or development quality.
Below, I've provided examples of deliverables that project managers are responsible for and proposed ways that Agile practices help us substitute, consolidate, or eliminate documentation for them. If these deliverables are required, minimum effort should be made to create the documentation.
Deliverables |
Description |
Is this Documentation Relevant? |
|
Project Business Case |
Kick-off document that explains why the project is taking place, including the desired goals, objectives, and outcomes. |
Not Needed. The kick-off document may not be relevant in an Agile environment, as goals, objectives, and outcomes change during project development. The fluid nature and flexibility of an Agile environment achieves the objectives and goals without needing to state this explicitly. For example, testing a hypothesis and making changes along the way achieves a better outcome than committing to an objective that may fail after the project delivers. |
|
Project Charter |
The document lays out the high-level scope of work to be completed; the requirements, timeline, investment (resources and budget) required; the definition of done; and project success factors. |
Not Needed. In an Agile environment, a project charter is never mentioned or created. As high-level scope of work of MVP (Minimum Viable Product) has been defined, and stories are prioritized and groomed for development work, feeding the work to a static project team with a fixed budget will negate the need for a project charter. If a project charter is required, a short, 1-pager should suffice. |
|
RACI Matrix |
The RACI Matrix is a great way to define and assign responsibilities. The Matrix charts who is Responsible, who is Accountable, who is Consulted, and who should be Informed. Mapping this out helps to reduce confusion, distribute workload, and increase efficiency. |
Optional. A RACI matrix in a scrum environment does not need to be overly complicated or detailed. The need to identify stakeholders as accountable, responsible, consulted, and informed may depend on whether the scrum team feels it is useful and helpful. In my experience as a scrum master, a RACI Matrix is never brought up unless there is a specific need for it. |
|
WBS (Work Breakdown Structure) |
A work breakdown structure is the core of project planning, resource management, and avoiding project scope creep. |
Not Needed. WBS is a great tool for tracking waterfall projects; it is used to identify dependencies and reporting on the % of work done/remaining. Because of the iterative development in a scrum environment, percentage completion is not the measurement since the project team is committed to completing 100% of their work within the iteration. |
|
Risk/Issue Log |
The Risk/Issue log is a log of all risks and issues the project may face. It is good practice to follow some sort of logging format; name or ID, description, impact, probability, proposed mitigation, and owner or person accountable. |
Needed. Tracking and calling out risks/issues is important. As a rule of thumb, the 3 top risks/issues should be identified, and the mitigation and owner/person accountable should be included and called out to senior leadership who can help prevent the risk turning into an issue. This is an important deliverable in any project methodology. During the retrospectives, this should be called out. |
|
Change Request Management |
Keep track of any formal additions or alterations to the agreed upon deliverables from any of the other project documents. |
Not Needed. Scrum would do away with change management since scope changes are managed in an iterative, 2-week cycle. Since the MVP has already been defined and stories have been created that make up the MVP, change requests are not needed. |
|
Project Schedule |
The project schedule determines which work needs to be done when. It gives the time frame for completing tasks and starting others. All work associated with a project should be scheduled. In some cases, it is a good idea to document the planned schedule and the current schedule so that late tasks can be flagged and properly addressed. |
Not Needed. Project schedule is dictated by the number of iteration cycles needed to complete the MVP. So a project schedule is no longer needed in a scrum environment. |
|
Lessons Learned |
Recording findings at different intervals of a project will produce better quality and more factual insights. The format and detail of this document will depend on the project governance and project management culture of the organization. The entire project team should contribute and agree on the lessons learned. There should be clear takeaways, and the final step is to share it with the wider team. |
Needed. After every showcase, a lessons learned, better known as retrospectives, provides a timely feedback of what was done well, what can be done better, and which impediments remain. This format of calling out these points after the showcases is highly interactive between the team members and the stakeholders. Blockers are discussed in this forum and escalated accordingly and appropriately. |
|
Project Communication Plan |
This will ensure effective communications amongst the project team and stakeholders. Sometimes it’s a simple list of dates with updates or meetings that may be needed. Other, more complex projects require email and document policies; status meetings and automated status reporting; and work, status, risks and issues. |
Not Needed. Project Communication Plans should no longer be necessary, as communication to the project sponsor in an scrum/Agile environment would be frequent and interactive. No exchanges of emails, documentation of policies, or status meetings are needed if weekly showcases are held by the project team and open to any sponsors or stakeholders. |
As shown above, I’ve listed the various deliverables that project managers are responsible for. There is no right or wrong answer as to whether these deliverables are needed, but eliminating them allows PMOs to re-invent themselves as enablers and drivers who can streamline processes. By making it easier for other people to do their work, PMOs add value to organizations since they become the change agents for the rest of the organization.