Project Management Reality
Warning: This post is more of an editorial than information sharing. This was the number one topic on my mind this week (aside from reading all of your great feedback!).
In my experience it seems that all ongoing or repetitive projects go through cycles with swings from very-process-intensive development periods to forget-process-lets-get-things-done periods. I find it similar to the moves we frequently see from centralized teams and processes to distributed versions of the same. That perfect balance - that which allows us to arrive at our goal on a predicted date while exactly meeting our requirements, all for the lowest cost in resources and in the shortest time - is the project manager's Holy Grail. Anyone who has taken Project Management 101 knows, however, that there is an eternal triangular battle when managing a project. Depending on who you talk to, the exact names of each side and middle of the triangle vary, but generally you can consider the sides to be: time (schedule...), cost (dollars, people...), quality (scope, level of excellence...). You can only optimize on two sides at any given time. What they don't typically talk about, though, is the method to the madness of project management - the balance between process and productivity and its impact on morale and how to handle project realities.
The reason I chose to blog on this topic today is because this is what I'm spending a significant amount of time working through, on two fronts: shutting down our current product (2005, a.k.a. Whidbey) and thinking of how we can improve our next development experience. With regards to Whidbey, there are forces pulling the project in either of two directions: take more time to shut down, or, get the product released and into customers' hands sooner than later. With regards to our releases after the 2005 version, this work is in regards to that balance I mentioned above - the best balance between tightening up our development processes with empowering and trusting people to really use their creativity and intelligence to do the right things.
Theories, Methods and Reality
There are so many theories on the "right" way to manage projects, and a large number of those specific to software development projects. There are of course many pragmatic methods (I'm currently reading about SCRUM). As with a lot of theories, and some methods, while we can do our best to carry out the best intentions of the theories, we often face the realities that make the process or method a challenge. The proud project manager will respond here with "a good process or method will be resiliant to reality." To that I will politely respond "pthhhhhh." Even the best running process around can be derailed by realities. Sometimes the best process or method can even drive down team morale!
What I didn't (I argue couldn't) learn in my undergraduate work is how to handle realities. There was definitely content around managing people and teams, along with risk management and the like, but it really didn't prepare me for the day to day project and people realities that seem to come primarily from experience: really being able to work with unknowns, handling the massive flow of information, dealing with unexpected problems (too minor to call "risks"), the spectrum of human issues, circular dependencies, managing without authority, staying productive despite dealing with ineffective people, the Murphy's Law where everything will fall apart at once if at all possible, the other Dilbert-like moments (and balancing all of this with your non-work life), and so on.
You have to learn how to work with your project with much grace and flexibility, diplomacy and patience, and, of course, a great sense of humor. This is why you need humans - not just processes and methods, software packages and tools - managing projects.
april
