Have you ever pissed a project manager? Not the work not done kinds; the one where the blood boils and the body shivers; I'll kill you kinds. I have, a number of times; and I can successfully say that I've escaped death and had a drink later. If you're one of those sadists who wish to become a successful project manager someday, this is how you be one. Well, not by frustrating your current project manager, instead by understanding the theoretical aspects of project management. Now I know when I talk about theory many of you'll say that bookish knowledge doesn't apply in practice. To those many, I say, this post is for a few good project managers who practice the correct theoretical concepts. Authors who write books, write experience. In short I cannot convince you if you don't wish to be convinced. But if you have an open mind, this 10 minute post can improve your project management skills by 10 times.
Two years back I met a couple of managers as a consultant to help them resolve a few project impediments. There were 3 basic pseudo-challenges that they were facing:
Our projects have never missed a deadline
We have an urgent requirement to fulfill
Failure may lead to loss of an old business
Why do I call these challenges pseudo? Let's address these one at a time:
1) Never missed a deadline:
Believe it or not, many practical managers believe that never missing a deadline is a problem. For them, never missing a deadline means that either there's not enough work or the team is too big at that instance (good for billing). Either way these managers tend to keep on shuffling people in and out of projects in order to optimally utilize them. After wasting a lot of unnecessary time & effort in shuffling people they boast about saving costs in management meetings (not time, which is money). This results in praises by the upper management and unnecessary pressure on the others. Now theoretical managers work differently. They understand that delivering on-time is the most important thing. So they constantly measure the team's capacity and estimate the velocity with which they can deliver. Of-course this means that they will hardly miss any deadlines (that's sad?). Also theory (and practice) suggests that constant shuffling of team members will cause a small amount of ramp-up time in transferring knowledge which in-turn will delay the project. This may lead to missing deadlines - is this what we wish to achieve?
2) Urgent requirement:
Let's define urgent. Urgent means something that requires immediate attention. Now, let's define urgent in software development. E.g.: With our current capacity we can deliver five features but we have promised our customer seven. With all due respect, this is called "being late" and not "urgent". How do practical managers react in this situation? They ask - How many people do we need? Will adding more people to the team solve this problem? Brook's law suggests that adding manpower to a late software project makes it later. Is this true? First, as explained above, ramp-up time is needed for new team members. Second, especially for agile teams, more people lead to more communication channels which leads to extra time needed to sync. And third, there's a limit to which requirements (or stories) can be split; beyond which adding more people simply doesn't affect the project timelines. In short, nine women can't make a baby in one month. But the manager's question is still valid: How many people do we need? The simple answer is one. The one theoretical manager who will explain these concepts to the customer and convince them to reduce the scope.
3) Loss of an old customer:
This is a classic. Managers typically fear loss of customers, especially if the customer has stayed with them for a really long time. This fear leads to loads of problems including introduction of unrealistic expectations. The longer the customers stay with us, the more the urge to impress them regularly. Practical managers begin to take unnecessary challenges like over-commitment. Motivated team members fulfill this over-commitment by pulling a few all-nighters. This leads to raised expectations by the customers, which in-turn leads to more over-commitment and more all-nighters. The question is how long does this model sustain? The truth is much simpler. If a customer has stayed with you for a really ling time, impress them by improving relations and earning good-will and making them understand your way of working (possibly reduce your billing rate once in a while). Possibly keep looking for new customers so that loss of old ones don't impact your business negatively. Although practical managers would say it's easier said than done, theoretical managers might say, when done it's easier to say. Although I don't deny that loss of customer is not a reality, failure will not be the only reason and there may be a number of reasons for failure as well.
Whether you're working in an agile project or not, situations like these may arise often and I truly believe that theoretical concepts if adhered to during these situations can reap much more benefits rather than fire-fighting your way towards success. Unfortunately practical managers capable of propagandizing (pseudo) results in a shitty situation are much more appreciated than theoretical managers who apply the right concepts and help a project sail smoothly to completion. If you are the later, don't be sad; begin pointing out the obvious and stand your ground. Nothing pisses off a practical manager more than a realization that theoretical concepts exist for a reason.