Just the other day I was thinking of some things to blog about that were fresh and new and it suddenly hit me that I've never really discussed project management related issues.
But what hit me harder (quite a smack on the head I must say), was what I subsequently realized -- very few of the software / architecture / java blogs I read talk about project management or related concepts? Now I'm talking not just about developer blogs but folks who are tech leads or architects, CIOs and CTOs!
Oh yes we talk about XP and other agile methods but it's all very "developer-centric".
That is, you don't see the following words very much
- "Project Plan"
- "Critical Path"
- "Dependencies & Sequencing "
- "Estimation & Budgeting"
- "Resource Planning"
- "Staffing"
- "Team Development"
- "Scope"
- "Risks"
Are we saying these things aren't relevant or aren't important? If these aren't the words we use when talking to our various project managers they sure as heck are the words THEY use to talk to their bosses and their bosses' bosses! Yeah - the guys with the $$$.
If Architect's don't think what Managers do is all that important, then we've got some conflict brewing. Nothing overt mind you, but lack of common goals and lack of common interests don't lead to the most productive professional relationships.
But how is it we can share the same tacit goals (timely completion, full functionality, happy users etc.) and not really be on the same page? True to an extent, project management and architecture/design are orthogonal issues - along different dimensions.
Also generally the PM, I've found, relies a lot on the architect for guidance and help in things like risk identification / mitigation and validating work estimates. But where do Architects rely on PMs? I have to say, in my experience, we don't - and that doesn't sit right. We can't be as successful as we want (need?) to be if there's a one-way dependency.
Perhaps that's why I've often heard managers express frustration about their technical leadership - if/when you're a PM and your project's success of failure (and thus your professional success/failure) depend on an architect and tech team that just doesn't speak your language and doesn't understand concepts such as how blown estimates really affect project plans -- well frustration must be expected!
True - frustration goes the other way too. Software is still more "art" than "engineering" or "science" and estimates can be way off for quite valid and reasonable reasons (e.g. a bug in the VM can be very expensive to work around). Being expected to meet deadlines when such things happen can be tough to swallow.
And perhaps that's the problem - we're applying project management techniques which we're perfected in the 40s, 50s and 60s when mass industrialization and mass manufacturing took off. But software is not nearly as mature now as those industries were then. Linear system thinking just doesn't apply nearly as neatly to the realm of software development (yet!).
Let's call this the "Management-Technical Impedance mismatch" in honor of two other things that really don't go well together but need to (Objects and Relational DBs)
That said, this mismatch doesn't absolve us from trying to bridge the gap and looking for the synergies. Technical folks need to acknowledge that these project management concepts, and what they represent, are important and ever present in modern business.
The communication needs to go both ways, but where to start? Take two books and call me in the morning! The Mythical Man Month is unparalleled and unmatched for elucidating some of the problems with some great stories. For a more prescriptive and more modern approach there's Steve McConnell's Rapid Development - just an incredible book.
Get copies for everyone on your team and see what happens! Anything that gives us a common frame of reference, with things we can agree upon is a good place to start.
3 comments:
Another book to help bridge the world between agile development and PMs is Agile Estimating and Planning by Mike Cohn -- apart from the development-side estimating techniques, I found that it really helped answer some of the questions I'd always run into when talking to PMs about Agile Development, such as "How do we handle the customer wanting a fixed-length contract?"
Good topic. This is the first place I actually read something about bridging the gap between S/W Arch and PM. There is definitely a need, but you never hear about. Often tech people view the PM as the necessary evil to buffer themselves from the business people's constant harassment. While PM's can sometimes view tech people as introverted reclusives who should code and code alone. I think if both PM and S/W Architect can find common ground the chance of project success if much greater.
I was trying to understand how PA and PM are related in terms of career growth and responsibilities. I have seen that, in farely large organization, artichects are more or less independent fellows, whereas project managers are responsible for many things to run the show. Also there are many professionals available, working in capacity of managers -- people managers And project managers -- but there is a huge gap between these two authorities.
So, i believe that PM requires generic knowlege but PA needs generic knowledge in management as well as technical knowledge. Therefore, PA with PM skills can best resolve conflicts.
Post a Comment