The Process Paradox
If it feels like process, it is not working… It should feel like a logical means to achieve an end.
For much of my career as a Project Manager I have been inundated with software development process, theories, techniques, methodologies and related tools - which by association has trickled into the teams I have worked with. Over time I have observed team members feeling the frustration that “Process” can bring to a project when it is applied in a theoretical way vs. a practical way. Have you ever facilitated a planning meeting while team members glaze over and bury their heads into their laptops? To all my Project Management brethren - if this is something you are observing in your teams, don’t accept this reality; realize that your process “is not working”.
The art of project management is not dictating process but finding practices that align with the team’s needs and context. For purposes of this blog post these are the “logical means” I refer to in my opening statement above. A little Scrum here, a little Waterfall there, and a sprinkle of Kanban might be the right recipe for a particular project - whereas it could be totally wrong for another.
In many ways this context is driven by the pyramid of constraints - cost/scope/time, which is project management 101. However, other contexts might be size of team, remote/co-located, green-field development, team member experience, criticality of deliverables to human life, number of stakeholders, thick/thin management hierarchy, complexity of business rules/logic, and many others which are industry specific.
One of my biggest gripes with the “Agile” movement is that companies/teams are adopting variations of the methodology as a prescription to execute projects. I am pretty damn sure the pioneering thinkers who wrote the Agile Manifesto wanted teams to become more principled in thinking about the practices they chose to use vs. following the playbook blindly and not making sure it aligns with the project context.
It has been very affirming to know that engineers and designers in large and small companies loath process – I’d say this is pretty universal. However, I have found that these same people are incredibly logical people who are willing to do something non-engineering/design related if they feel deep down it is a “logical means to achieve an end.” I believe it is the project manager’s responsibility as a servant leader to make sure teams don’t feel like process is holding them back but that it is helping them move forward.
What I love about being a Project Manager at DockYard is the diversity of the project contexts that come through our door. For me it is and has been a great way to experiment, mix, and match processes to find the right practices for a team/project context. I believe that DockYard’s acknowledgment of this reality allows us to better serve our clients’ unique contexts. Not by accident - it is a very deliberate way to approach projects and one size never fits all.