The challenges and benefits of project management

Project management is a truly universal skill, required across all business domains, all geographies, and all the time.

The language of the project manager is the same across all fields: a software project manager can talk about schedule compression and a civil contractor will understand it perfectly, even though the rest of the other's professional terminology might sound like Greek to them.

But there are two misfortunes in this field:

• The first is that people who have been a part of a project at some point in their career will think that they can take on project management with no preparation whatsoever. It is also true that engineers will get promoted to project management roles by their boss, without verification of their aptitude or the downtime required to prepare for the role. Technically competent entrepreneurs start companies based on their passion, and then realize they also must manage organizational projects, which ends up being much more than the amount of work required for their product.
• The second misfortune is that, often, project managers who have had only academic training and certifications think they can take on a project beyond their capabilities.

Joel Spolsky, program manager on the Microsoft Excel team between 1991 and 1994, and cofounder of Stack Overflow, jokingly quipped in an essay about the existence of two mutually exclusive sets of genes: one for software development and another for management. The message is that the skills required for a technically oriented person and for a project manager are very different. And it is difficult for both to co-exist (but not impossible). There is more than a grain of truth in Joel's observation, no matter which business domain we look at.

It is all too common that the rock star performer of the team gets promoted to be the project manager. And they will find themselves doing something they have never been trained for in their lives, and often do not even have the aptitude for it.

The story is very similar when it gets to Microsoft Project.

The project manager fires up MS Project and because it resembles Excel a little, will innocently expect it to behave similarly. Very soon, they encounter the vast array of options and complexities of automatic scheduling, eventually giving up. Project management is very complex as it is; how do we use a software tool with a steep learning curve?

A few PMs might take a course or a book because their organization mandates the use of Microsoft Project. But then, they will not venture beyond creating a draft schedule at the beginning of the project. And there it will remain in the repository—uncared for, unloved, and never updated.

I have already heard a thousand different versions of this same story from my learners. And that is why this book aims to solve these specific challenges. If you complete the book while practicing all the hands-on examples simultaneously, then you will not be intimidated by Microsoft Project and your schedule will be a living document because it will reflect the true state of your project. Moreover, your boss (and their boss) will love your reports (which you can pull at the drop of a hat).

The Iron Triangle (Triple Constraint of Project Management)

Every project in real life is bound by constraints. If there was unlimited money or unlimited time, would there be any real challenge in project management?

You will have already heard of the famous Iron Triangle (or Triple Constraint) of Project Management:

Figure 1.3 – The famous Iron Triangle of Project Management (also known as the Triple Constraint)

The story is that, if your customer asks for good, fast, and cheap, you say, choose any two. The third parameter is your room for negotiation.

This concept is grounded on common sense and its origins are probably lost in the sands of time. And you will find multiple interpretations of it, each with a slight variation. But the gist is that any single vertex of this triangle cannot move without also impacting the other two.

Say you were building a house for a project. After all the planning, you start the project. Your significant other and your children now remember that they always wanted a swimming pool and you haven't factored it into your plan. At this stage, you will know that the additional scope means an additional cost and a few extra weeks, right? Moreover, if you don't have the luxury of extra budget or time, the quality of your project will decrease. This is what the Iron Triangle is all about.

And even this Triple Constraint model itself has a constraint. There are limits to which you can stretch this model, after which it breaks.

In his legendary book on software engineering and project management, The Mythical Man-Month, author Fred Brooks expounded that adding manpower to a late software project makes it even more late. This was written way back in 1975, and with the exponential expansion of software complexity and usage everywhere, the book's message rings even truer today.

The reason for this is that given that a project is already under pressure, adding more people to the team leads to added communications, additional requirements in the design interfaces, more training to get team members familiar with the project (requiring key team members to conduct knowledge transfer meetings), and so on. This will continue to the point when the project gets even more delayed than it already is.

How MS Project helps with the Triple Constraint

Microsoft Project's powerful automatic scheduling feature makes it a breeze to calculate the impact of additional scope on a project. Moreover, Project also provides some resource costing features that can be layered on top of your scheduling. We will see all these features in action throughout most of the book.

There are, of course, caveats: the additional scope should be well defined enough to be added to the schedule for Project's magic to work.

Microsoft Project and the mythical man-month

The mythical man-month predicts the drop in productivity caused by adding additional resources to a project. This unexpected reduction in productivity will be industry specific and largely depends upon the circumstances of the project. It is also very difficult to objectively quantify this productivity drop due to the unique nature of projects.

While it is possible to simulate such an effect using MS Project (by decreasing the resource units assigned to a task), it is very rarely practiced in real life. In the words attributed to the same author, Fred Books, everybody quotes it, some people read it, and a few people go by it, referring to the mythical man-month.

The elephant in the room (failure rates)

Despite the collective wisdom of millennia in project management, all studies show that the failure rates of projects are appalling. What constitutes a failure is generally acknowledged as overrun schedules and budgets, the unacceptable quality of the project result, or ultimately, the desired business objectives not being met.

While the inherently unique nature of projects builds a certain amount of risk into projects, it is also true that certain patterns can be observed from failed projects. We can immediately learn the following points from them:

• A higher complexity, size, and duration leads to failed projects
• Unrealistic schedules lead to real failures
• Not investing in baseline and variance analysis can be detrimental to project health
• Not tracking costs can sink the project ship

Winning – but at what cost (burnout rates)?

Poorly managed projects will cause teams to burn out. We have all heard of project managers leading teams into toxic work schedules, with no downtime to meet the unending Death March of projects.

Burnout, a word coined in 1974 by eminent psychologist Herbert Freudenberger, refers to the mental and physical breakdown of individuals caused by work-related stress. Unrealistic project schedules with relentless work hours, Kafkaesque expectations, extreme market conditions, the apathy of management, and any number of other factors, often simultaneous, can cause burnout.

And also, the world has tended to hero-worship the notion of project managers who pull off incredible goals. Steve Jobs, the charismatic cofounder of Apple, created what was half-jokingly referred to as the reality distortion field across the software industry. Jobs would use his personal charisma, hype, fear, or any other tools at his disposal to convince teams that anything he said was possible, especially fantastic project timelines.

This discussion would not be complete without mentioning the state of today's multi-billion-dollar video game industry. This industry, perceived by newcomers as fun, modern, and happening, has inordinately high burnout rates. Project schedules are perpetually in crunch mode. There is high churn in teams, which means that burned-out developers leave the company and brand-new workers are recruited into the company. Inexperienced developers, mostly fresh from college, are recruited for their ability to work long hours until burnout. Then they are churned out to make way for a fresh set of developers.

Project managers, like you and me, are at the frontline of the battle against burnout. Often the first impact on the team is on the PM themselves. The fight against burnout in all its forms should also begin with us. Today, there is a wealth of information to identify, prevent, and recover from burnout issues.

Where does Microsoft Project figure in the fight against burnout?

When a resource is allocated more work than they can handle in a standard workweek, it is called overallocation. Repeated overallocation over a lengthy duration is the first and foremost cause of worker burnout. This is not the same as the occasional crunch time that every real project faces – often during customer demos, or the final launch.

A project is stellar in identifying overallocation, and this is also recognized as the number one bane while creating your schedule. This book will cover overallocation with the highest priority, and we will discuss 10 different resolution techniques throughout the book.