Why Project Management Is Killing Your Business (And What to Do About It)
Endless piles of books, podcasts and conferences have attempted to tackle the thorny issue of how you manage the massive portfolio of projects in your organization.
Countless frameworks and methodologies have been developed, yet IT practitioners have yet to reliably solve how to execute, manage and scale project management.
With so many ideas and approaches, you’d think the problems surrounding project management would have been solved; that we would have found the ‘One Way’ to manage projects.
Not so!
Some strategies tend to work better than others, but I’ve seen countless organizations that utilize strict agile development processes consistently fail on the project management front.
As we will see below, what project management failure means in practice is that you disempower your developers by limiting their autonomy and ownership.
And taking power away from the people that are driving the digital innovation you need to survive is going to kill your business!
Why Is Project Management Killing Your Business?
“If everywhere you go, it smells like crap, maybe it’s time to check your own shoes…”
The methodologies and frameworks aren’t the issue. The people aren’t the issue. The tools aren’t the issue. So what is it? I believe the problem is at a higher level: the management of project management.
Traditional project management is managed and operated centrally. Your entire organization likely has a single Project Management Office that is separate from the many diverse development teams. What tends to result is that all projects are subject to a singular workflow that specifies procedures and processes along with the centrally-owned tools that track work for organizational reporting.
The core problem is this: you cannot possibly prescribe a single method for every single task across every single development team!
This creates a host of conflicts between your organization and your developers:
1. Your developers have limited ownership of, and accountability, for their work
Many of the core tenants of modern IT revolve around an extremely critical theme: ownership and accountability. High-performance IT is directly correlated with high levels of ownership and accountability among teams.
But traditional project management separates itself from the development processes by being managed and operated at an organizational level, cutting developers off from the decisions about how they work!
2. It creates a conflicting incentives between departments
Centralizing all operations and project management at the organizational level creates a leader-follower dynamic for development activity.
The problem is that the centralized management teams (leaders) have different incentives than the development (follower) teams. Development teams are often incentivized by their throughput, or ability to release new features and respond to issues in a timely manner. Centralized management however, is more interested in ensuring process and compliance is followed, regardless of whether this negatively impacts developers’ timelines.
Misalignment is inherent in this model, because this control naturally creates friction in the system, leading to missed dates, frustrated employees, frustrated management, and frustrated project managers. Over time, this chaos causes the problems to compound upon themselves, leading to some sort of significant IT shakeup—such as reorganization, budget realignment, ownership and responsibilities reviews, etc.
3. It drives productivity into the ground!
A narrative I see time and time again is the following: “We’re using Agile and every sprint is two weeks, and every team operates on the same sprint cycle, and all tickets are tracked in this tool, and we run weekly reports of ticket velocity to management and review individual tickets with them...so you better be closing your tickets on time as tickets represent work performed!”
The disconnect with centralized governance here is questionable performance-based measurement. This creates a culture that disenfranchises the employees it oversees.
This is a fantastic way to drive actual productivity right into the ground!
Organizational metrics looking to understand velocity through tracking don’t actually have anything to do with productivity, but rather with an abstracted proxy of productivity.
In practice, this approach puts pressure on teams to react based on management opinions rather than customer needs. These metrics can and are gamed. Working this way is also a fantastic method of getting your talented developers to quit because they can’t deal with the bureaucratic overhead of the model.
How Can You Stop Project Management From Killing Your Business?
Instead, the focus of project management must be on enablement; undoing the separation and conflict that causes project management to fail.
Team enablement is critical to the long term success of any organization. Ownership is the cornerstone of enablement. If you don’t trust your developers to deliver with relative autonomy you are not only limiting them, you are also ensuring that you are not getting an accurate picture of the amount or quality of work being performed.
Your project metrics should be centered around realized business value, not how many lines of code were written, nor how many tickets were closed. Allow the teams some say into how their work is tracked and managed and the teams who care about their work will be interested in making the situation better for everyone.
In building a culture and balancing the organizational guidance for success two paradigms are critical here:
- Alignment: Development teams must be aligned around products, not projects
- Ownership: Work on those products must be owned by the teams themselves
It is a given that project management and organizational oversight is necessary in every organization. To find a balance between what the team needs to sustain itself and what the organization requires for oversight we find that the team must have a say in their project workflow.
What Does This Look Like In Real Life?
I often joke that the most important thing I ever did for one team was to create a new policy for how their projects and release management operated.
The change effectively gave them special dispensation from change control boards and all other centralized project management processes. I took the new policy through all the bureaucratic processes to get it officially signed off, and instantly the team’s time to production went from every two weeks to hourly. At that rate, problems don’t take long to fix and new features can be released extremely quickly, shortening the feedback cycle time between you and your customers. Now, this only worked because the team was top-tier talent and could be effectively trusted to handle this responsibility. This does not apply to every team in all organizations, but it clearly indicates what the direction of travel should be: as much autonomy as can be granted within the context of your organization.
Between centrally controlling every minute detail of how projects are managed and total laissez-faire anarchy, there must be some form of common ground that allows for accurate tracking, reporting, planning, and the like, while still allowing good teams to shine in their own way.
How to Find the Right Balance
Here’s the part of the story where I don’t give a straight answer and stick to generalisations, because how to handle this problem ultimately depends on your particular organization: its tolerance for risk, its requirements around reporting and roll-ups, how its budgets are planned, and how much it trusts the development teams. To further complicate matters, even starting this conversation internally can be portrayed as potentially insubordinate or completely impossible.
Addressing these types of issues is daunting. Even if you have the authority to dictate a new process tomorrow, that will only introduce more chaos and headache. The best way to approach any change of this type of scale is to experiment and continuously adapt your approach as you expand it across your business:
- Pick a team: identify a productive and forward-thinking team to test approaches with
- Start small: identify an area of limited scope to improve, for instance, change control processes
- Work directly: determine the best path forward directly with the team and allow them to experiment with varying approaches
- Iterate: learn from each change you make and incrementally improve over time
- Scale: expand best practices and learnings to other teams
Gathering insights from your developers on the ground is a crucial step in figuring out where to begin. Here are some questions to guide you:
- What issues do they have with the system?
- Do they believe that their productivity is fairly communicated to management?
- Do they even know how the metrics work and are being communicated?
- What processes cause the most pain?
- How would they prefer to work?
Compromise with the governance team and the development team. Get a special dispensation to change the way work is tracked, and then continue to work with all parties to understand what is working and what is not. If a team wants to stop using the centralized ticketing system, is there a way to obtain a similar metric from the team (story points completed per sprint, for instance) that can be communicated in a similar fashion to the other metrics?
Try a few strategies out and see what works. Then you can begin scaling to other teams and eventually change your whole organization!
Don’t let the management of project management kill your business!
