I have gone on record before stating how important it is that project managers and Software Development Management in general cut code. This is a bit of an unpopular position as the Project Management Institute (PMI) and others feels that a non-technical project manager is just fine and in some ways an advantage. You will even find that a good majority of Project Managers may not have a degree in Computer Science. The PMI concept is that you should be able to manage scope, schedule, and time without detailed knowledge of the work being done.
To this I say – Hogwash
The only people who every propose this position are non-technical Project Managers. You never hear a technical Project Manager state how little his experience actually helped him. You also never hear any professional athlete state how he wants a coach that never played the game.
We can distill why technical experience and expertise is important down to two reasons:
1) Trust and Credibility – Trust and credibility isn’t given on account of status by any professionals. While some non-professionals may allocate trust based on rank, Software Developers, Engineers, Accountants, Doctors, Lawyers, etc need to confirm you are credible before allocating any trust to you. If you don’t have some scars and experience in the career domain, that trust will have to be earned on the project. You will not be a high-performing team until the entire team has this trust and credibility. So while this can work, it certainly isn’t the preferred situation.
2) Context and Domain Knowledge – Besides gaining the trust of your teammates, having the context and domain knowledge in Software Development processes is essential. How else can you decide whether something is truly an issue or if it is a minor inconvenience? What about determining if a plan or process is realistic or valid? The best way to judge these situations is first hand experience.
Why is this so important? It again occurred to be as I read Glen Alleman’s Blog on “Why Software is like Construction“. The Blog is a good introduction to the basic premise and theory of the 3 pillars of Project Management. But I feel it is an overly simplistic view of project management in any domain. Yes, this is how the books teach you but it is the project management equivalent of a Physics problem without considering friction. It is true and valid and with very little information that will assist in the real world.
The “What” is always easy. The difficulty and expertise is always in the “How”
The idea I took away from the blog is this:
“Anything looks simple if you get far enough away from it”
From a 50,000 foot level, Farming and Mining look very similar. Both are labour intensive, involve the land, use machinery, and sell the proceeds at a profit. All that is different is the tools that are used to produce the end-product. So how hard should it be to manage projects in either domain with the same processes and knowledge? Can’t we just balance the three pillars? Yes and no. While you can balance the three pillars similarly, the consequence of your decisions has have far-reaching and drastically different impacts.
Anybody that has cut code on a Software Development project understands that. Developing a technical solution is much different from building a bridge. A bridge is a repeatable process that undergoes evolutionary change in the process, Software Development is a non-repeatable process that undergoes revolutionary change every 6 months. If you don’t recognize this fact, you are probably flying above the project at about 20,000 feet. These differences will require different project management skills and problem solving. Trying to apply the same corrective measures from bridge building to Software Development can be catastrophic.
I recently was able to project manage a research and development project.This was a new experience that made me appreciate the complexity of a Software Development project even more.
I would like to start a new certification that ensures you need to cut code that gets promoted to production every year to maintain your Software Development Project Manager designation. This would be similar to the PMI designation that requires a certain amount of credits every two years, except that the only activity that qualifies is cutting code that is deployed to production.
I’d even like to see a ticker on everyone’s blog that count’s up from when the last code they wrote was deployed in production. Very quickly we would see how many feet they are flying about the ground and whether they have context to advise us on how to farm wheat under a prairie sky.