The project manager, an architect of projects – Sridhar Krishnan

Print Friendly, PDF & Email

This essay is by Sridhar Krishnan.

Visualise a typical IT project.  Now, picture the project manager.  What comes to your mind?

For most people the stereotypical image of a project manager is one of a harried individual scooting around with a project plan, attending project reviews with the client, moderating an endless stream of team meetings, authoring status reports, poring over budget tracking spreadsheets, negotiating with the boss for resources, fighting fires, ad infinitum.

More pertinently, how does a project manager visualise her own role?  Does she also see her work as a frenzied series of activities stretching from the project’s starting block to the finishing line?

Much of this frenzy is indeed a part of every project manager’s life.  That’s the nature of the turf.  But the challenge – to the project and the effectiveness of the project manager’s role – arises when the dividing line between the important and unimportant is allowed to blur quickly and permanently.  And this, unfortunately, happens all too frequently in many IT projects.

Overcoming this challenge requires project managers to visualise their role in a manner that lends greater structure to their work, helps identify and stay focused on priorities, and present their role to project members and stakeholders with clarity and conviction.  I proffer that one way to develop a good mental map of her role is for a project manager to examine it in the same way that the project’s solution architect looks at his role.

Before we go further down that track, there are two prerequisite points to be made.  Firstly, just as a typical software development project delivers a system that meets a stated business need, the project endeavour itself – with its various moving parts such as people, tools, processes, etc. – is also a system, albeit a temporary one. This transient project system exists only to – and for only as long as it takes to – deliver the target IT system and any associated organisational change.

Secondly, in leading the design of the end system the solution architect applies a certain set of principles that establish the design priorities and ensure the system’s conceptual integrity.  A similar set of principles, interpreted differently to suit the context, lend themselves to be applied by the project manager in building and running the temporary project system.

The graphic below tells the story.

What’s the benefit in casting the project manager’s primary responsibilities using this different perspective?  As I’ve mentioned above, it is intended to help project managers visualise and present their role with greater clarity, and to enable their priorities stay firmly in focus.

I will go further to suggest that if project managers see themselves not just as managers, a term that can often have nebulous interpretations, but as architects in charge of building and guiding the transient project system, applying specific principles to assure the integrity and effectiveness of this system, they will bring greater clarity of purpose and action to their roles.