Project Management to me is like the theory of multiple universes. Somewhere, out there, there may very well be other people, planets and stars, and we’ll never see them or measure them, because they exist within different laws of physics. But at the same time, the number of those other universes are infinite, the theory goes, bringing rise to an infinite number of possible experiences – human experiences – including other people just like you and like me, living out there. They have evolved and led lives just like ours, to the point where they would seem indiscernible to us at first. But the subtle differences in their decisions start to make their universe look a lot different than ours… each decision creates a new reality, and pretty quickly their world becomes drastically different than our own. The outcome of a project can end up being just as infinitely different as another dimension.

You can start with one set of players, and one set of requirements in a project, and quickly branch into an any number of outcomes, all depending on the decisions each player makes. How the lead developer manages their own time, how much buy-in the principal designer gets for their vision early on, or how the project manager presents requirements so the team can easily consume them – all the little, subtle choices by each person makes can add up to an outcome a universe apart from what was needed. It is my job as a project manager to foster & ensure good decision making on everyone’s part, not just my own. I believe every project has an infinite number of outcomes, no matter the planning methodology used, and we need to get the work to the outcome of ‘successful launch’.

No matter how well rehearsed the plan, success falls on the shoulders of the people committed to the project, and how they react to the tasks and challenges on each day of execution. It is up to me to set the tone and inspire a healthy mindset of the team, as much as possible, so that each of our decisions can lead us closer to creating our own universe of success.

Now this is not to say that picking a good methodology is not important – it’s crucial too. I am partial to Agile in it’s many forms, particularly with the emphasis in fostering trust, both inside and outside the team. Creating an environment where participants feel they have the trust of leaders and of colleagues, when achievable, allows for some of the best decision making possible. You are more likely to ask for help when you believe you won’t be severely judged. You can admit mistakes more readily. Developers can avoid ‘defensive’ programming, where they would just do what they’re told verbatim and not think critically about what is being asked of them. They are more likely to dialogue with other technologists and find collaborative solutions. Elevating trust to an official organizing goal of a project is a bold and welcoming approach to me, and I think it reflects the group dynamics of human nature accurately. And the extra motivation that can be injected from obtaining mutual trust is invaluable.

But Agile is not right for every project, and of course building trust is just one aspect of Agile. Ultimately each project will be suited to different methodologies depending on it’s nature. Heavily regulated industries with extensive prior-approval of designs do not lend themselves to the iterative development cycles (though building trust proactively has it’s benefit in Waterfall approaches too). I have learned ultimately that a methodology is only as good as the people who execute it – in their level of dedication to the chosen approach and to how their perceive their roles, including the level of buy-in and participation from business leaders in the approach as well.

And of course a team member’s mindset can only be molded so much by a project manager. How they make decisions and view their own role may be hard set by precedent, training, and even by other project managers. So when I enter a new organization, I set out to learn what the culture is and to work within it – elevating the most productive aspects and proposing changes to less productive processes.