While in my thinking room (the shower), I had a revelation. I have been trying to figure out why I keep seeing Project Manager positions being posted with very, very specific experience requirements. This is fairly specific to the software world (with some exceptions like federal contracting and nuclear) where the PM is expected to bring a very deep toolkit of experience to the project.
In my way of thinking and experience, I have often said that PM expertise is generally transferable between projects, technologies and domains. These specific experience job postings had me confused. My epiphany was that the software world has tended to combine two roles that you will find separated in other domains. Those are Project Manager and Technical Lead. In other domains, the Technical Lead is the person who defines the technical requirements for the project while the Project Manager “manages” the execution. These are two very clearly distinguished roles that are well understood in the more mature PM environments.
Just an epiphany that I wanted to share with everyone.
In the software development world, the term “Waterfall” has the same connotation as “green, oozing slime”. Unfortunately, there is good reason for this.
Having come out of the Engineering/Manufacturing world, I am fully versed in executing projects in the classic, pre-planned environment. There are any number of reasons why projects need to be done in this way (the subject for another discussion at a later date) and it is difficult to do software development in this environment. However, with good planning and management, it can be done (I have proven that). Part of the reason that we can be successful in developing software in this environment is that the requirements are well thought out and documented at the beginning because the customer environment is well understood and definable. At the same time, the hardware aspect of the projects are typically larger than the software and much less subject to change. This gives the entire project a different flavor than software only projects. This is the same issue that is presented when you have a project where there is a significant hardware component (typically seen in embedded applications).
But, getting back to my original thought, I think that one thing that we need to understand is that that classic, pre-planned approach to projects (i.e., Waterfall) is not a requirement, merely the most common approach to Project Management. At the same time, we it is completely feasible to take the concepts of Project Management and, if we understand them, apply them to Agile Project Management. It’s all the same thing, just a different set of priorities and processes.
Take for example the fact that every project has requirements (functional specs, user stories, use cases, whatever) and costs and schedules / deadlines. The only significant difference between classic and agile projects is that these are prioritized differently. The processes in the agile world are designed to deal with a highly volatile set of requirements. The classic world assumes that the requirements are significantly less volatile while adherence to cost and schedule are critical.
For a great, in-depth look at this issue and to learn more about the relationships between the classic and agile Project Management worlds, see Michele Sliger’s book “The Software Project Manager’s Bridge to Agility” (you will find it at Michele’s website: Sliger Consulting. I highly recommend it.
Its amazing how time flies and how many directions we can follow. I feel like I have been run through the wringer since I started to bring up this blog. Its been a wild ride with the BBSI development project and the changes at FSD as well as the change in the funding strategy for these efforts. Now that they are on hold, I am out looking for more work and/or investors for BBSI. If you are looking for a good place to put some angel investment for a medical laboratory device, just let me know.
In addition to my normal work, I am continuing as the Treasurer for the Mile Hi Chapter of PMI. That job, which includes the OnePMI website service, definitely keeps me busy (maybe too busy??). Anyway, its fun and has some perqs that help to offset the long hours.