Project Smart ~ Exploring trends and developments in project management today

Calendar iconNot recorded
Adobe PDF icon

Project Leader, Manager, or Monitor?

~ By Kendall Miller

Group of three office colleagues working collectively on a project

As I work with different clients doing software development, I've been struck by how different the Project Managers are. From what I have seen, the people in the role of Project Manager tend to fit into one of three archetypes:

  • Project Leaders: Command the technical respect of the development team and the business respect of the client. Generally could write the software if necessary, but it isn't an appropriate use of their time. Nonetheless, they frequently review code and occasionally contribute something because they just can't help themselves.
  • Project Managers: Typically have experience in either the client's business or general software development, but augment that with specific training in project management tools and principles. Don't contribute or review code, but actively participate in functionality and technical discussions.
  • Project Monitors: Are trained in project management tools and principles, possibly deeply up to and including being a Certified Project Management Professional. Wouldn't dream of contributing or reviewing code, can't actively participate in technical discussions, and can only lightly participate in functional discussions.

Here's the question: What type of project manager do you need to have for the best outcome of a software development project? For the sake of discussion, let's say the best outcome is the one that produces:

  • The most capability, closest to schedule, with the fewest defects discovered in the first 90 days after release.
  • The clearest understanding by the participants and internal observers of the status of development during the project.

The first item is the real challenge, because it revolves around the fundamental software development triangle of quality, functionality, and schedule/budget. The problem is that only one of them is really a variable - functionality. Few people will view a project as being successful if quality is significantly adjusted or if the project is late. An experienced team can optimise the effort put into quality assurance, but the largest swings in project effort come from dropping or changing functionality to either save time or eliminate defects. A feature not implemented is a feature that doesn't have to be tested and proven.

Adjusting functionality to save time seems very simple on the surface - remove new features from the list and the development time that was estimated can be applied to other aspects of the project. The challenge is - how much time will you really get back if you drop a particular feature? Rarely are features so isolated that this is an easy question to confidently answer. Secondly, what is the probability the feature will stay dropped? What may not seem essential to the development team may be the cornerstone reason your sponsor is funding the project.

To make effective decisions about what features can be cut or reduced, you need to be able to:

  1. Clearly understand the true incremental benefit in time and quality to the project of the change.
  2. Clearly understand the ability of the project's customer/stakeholders to accept the project as being successful even if that feature isn't available.

This is parked squarely at the intersection of technical and business expertise. If you don't know enough about the customer, the feature won't stay cut - it'll come back at the request of the people funding the project, and usually do so at a much less convenient time. If you don't know enough technically, you will tend to over-credit the project schedule for each feature removed. Developers are optimists: They will tend to underestimate how much work it will take to deliver on features in the product, and overestimate the initial savings of removing a feature, particularly if it's problematic to implement.

Pick Your Battles

Project Leaders - those that have the technical and business skill necessary to intuitively understand what it means to add or remove a feature - are most likely to produce the best outcome on a software development project. They still need to know the techniques and tools of project management - otherwise you won't have the clarity around the project necessary for people to view it as being successful - but they need to come at it with their business and technical hats in equal measure.

Project leaders are in very short supply, so what projects need true project leaders and which can still be successful with project managers or even monitors? Think of the difference between flying a plane and driving a train. A train is on tracks - you only control one variable (speed). Planes have many more variables - not just traveling in three dimensions but also complexities of many more external interactions. A Project Monitor could drive a train. You need a Project Manager for plane, and your Project Leaders? They're for the fighter jet on a combat mission.

Monitors can track what's being done, Managers can contribute to how it's being done, but a Leader understands deeply why it's being done and can change up the game when needed to win.

Key Times To Pull Out the Big Guns

Projects that break new ground: When the team will need clear guidance on what's crucial to deliver and what it means to deliver. A leader can achieve more than the others not just because of the other attributes already described, but also because the team will accept tactical management better because of the leader's technical credentials.

Teams with strong personality conflicts: In this scenario you need both peacemaker and mutual respect, so strong technical and business credentials are important to get each party to stop talking and start listening, then to carry through on the project together.

Projects with no obvious variables: While it's somewhat of a hyperbole that a project can't tolerate a change in schedule, quality, or functionality it does sometimes come to pass. In particular, some projects have hard deadlines that are externally imposed and are non-negotiable - like compliance with a government regulation or natural business cycle (the holiday season). These projects need to emphasise creativity in approach to achieve results within tight constraints.

Distributed project participation: When the project is very distributed or requires significant interdisciplinary involvement for success it requires a wider range of business and technical skills to bridge all of the small gaps between mindsets. This often requires a fine listening for what people are repeating back to detect deviations from course while they're still small enough to fix.

What Are You Looking For?

When looking for new project "leaders," most corporations emphasise project management skills and techniques - IPMA Level B, PMI Certification, and heavy experience with Microsoft Project or some enterprise project management software package. Not surprisingly, this tends to attract project monitors, not leaders. The next time you're lucky enough to participate in the selection process of a project manager or leader in your company, think about the hard skills you can't easily teach them first.


Kendall Miller has been designing, creating, and deploying information systems (hardware, software, and networks) since 1993. He's focused on translating large, sophisticated enterprise systems into affordable, workable solutions for smaller environments.


Comments

Be the first to comment on this article.

Add a comment



(never displayed)



 
2000
Is it true or false that twenty is a number?
Notify me of new comments via email.
Remember my form inputs on this computer.

The Risky Business of Project Management

Three red dice reading: Manage your risk

It is important at the beginning of any project to go through the risk identification process. Not all project risks are obvious, so here's how.

Project Planning Essentials

Tablet computer with project manager app and documents with Gantt and financial charts

Planning a project requires putting a series of tasks in order and determining dependencies between them. In practice it's never so straightforward.

Better Risk Management With PRINCE2

Red flowchart showing risk element

PRINCE2 has always had a solid, but simple way of dealing with risk. With the latest version a number of excellent ideas and concepts have been introduced.

72 Project Management Tips

Hand holding a key with success written on the fob

Here are 72 project management tips designed to help you lead your projects with skill, authority and grace.

PROJECT SMART is the project management resource that helps managers at all levels improve their performance. We provide an important knowledge base for those involved in managing projects of all kinds. With weekly exclusive updates, we keep you in touch with the latest project management thinking.

WE ARE CONNECTED ~ Follow us on social media to get regular updates and opinion on what's happening in the world of project management.


Latest Comments

Aimee Windmiller-Wood commented on…
Top 10 Qualities of a Project Manager
- Thu 23 February 5:06am

Liam commented on…
High Anxiety: Managing Projects With Your Pants Down
- Fri 17 February 9:27pm

Daniela commented on…
Better Coaching Using the GROW Model
- Thu 2 February 3:21pm

Latest tweets

General Project Management • Help With My Project Management Dissertation https://t.co/EoVJgBqYum #projectsmart #pmot about 4 days ago

General Project Management • Prince2 Advice https://t.co/pP7mAnGTJP #projectsmart #pmot about 5 days ago

General Project Management • Re: Interview Help 30-60-90 Plan https://t.co/BNA7TTqz1I #projectsmart #pmot about 5 days ago