Project Leader, Manager, or Monitor?
By Kendall Miller | minute read
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:
- Clearly understand the true incremental benefit in time and quality to the project of the change.
- 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.