Last month, I wrote about the differences between leadership and management, specifically how companies or projects that have management without leadership are unresponsive to change and how companies or projects that have leadership with no management are chaotic and unpredictable. Today, instead of the management-centric model of the late 20th century, more and more software projects are delivered via Agile, whose goals are more about being responsive to change than hitting an arbitrary budget. In this new world of embracing change, is a project manager the right person to be leading projects?
Before I can answer that question, I need to introduce you to two people I've worked with over my career. Both of them had the title "project manager", but as you'll see, each had very different jobs. I have, of course, changed their names in this blog to protect their true identities.
Before every project, "Beth" made sure that she understood what needed to be done, who needed to do it, and why it needed to be done. Years of asking these questions gave Beth a pretty thorough understanding of how all the parts of our process worked, even if she didn't understand the specifics of how we did our jobs. When we were planning our projects, she would often tell us what we could reasonably expect from other groups, and what could be possible if things went wrong. When things did go wrong, she would check to see if we could stay on schedule, and would either warn groups responsible for later phases of the project that they might be pressed for time or would inform stakeholders early that a schedule change might be necessary. This allowed everyone to make the adjustments necessary to make the project run smoothly.
"Mike" was also a very organized person. At the beginning of every project, he would ask for all the steps that needed to be accomplished to get a project completed, and he would put each of those steps into a spreadsheet. Mike was great at scheduling meetings and getting our questions answered. He didn't really understand what we did, though. We had frequent meetings that had no purpose other than for us to keep him in the loop as to the changes in the project, which for the rest of us was a waste of time. He also could not tell the difference between issues that were merely annoyances and the ones that were truly problems, so he treated them all with the same urgency. Mike was very good, however, at keeping everyone in the loop about the status of the project at any given time.
Yes, Beth is a better project manager than Mike. But Mike met the expectations of the company we were both working for at the time. Why? He was able to schedule meetings, facilitate communication, run reports, and inform the right stakeholders what the status of the project was. But since a true manager should help make processes run more smoothly and remove roadblocks for the team, Mike couldn't be called a manager. Thanks to one of my MBA instructors, I have a term for Mike's job, and it is a project administrator.
So circling back to the question of who really should be leading projects, I'd point out that neither Beth nor Mike led every aspect of their projects. IT personnel often forget about the fact that while software delivery is important, so is managing the other changes (whether culture changes for internal software or marketing efforts for external software) necessary for project success. Both Mike and Beth focused only on the implementation and delivery. So regardless of whether you have a project manager or project administrator, you need to have a leader preparing the business for the change. (I have more to say on that subject, but it will have to wait for another blog post.)
Before I can answer that question, I need to introduce you to two people I've worked with over my career. Both of them had the title "project manager", but as you'll see, each had very different jobs. I have, of course, changed their names in this blog to protect their true identities.
Before every project, "Beth" made sure that she understood what needed to be done, who needed to do it, and why it needed to be done. Years of asking these questions gave Beth a pretty thorough understanding of how all the parts of our process worked, even if she didn't understand the specifics of how we did our jobs. When we were planning our projects, she would often tell us what we could reasonably expect from other groups, and what could be possible if things went wrong. When things did go wrong, she would check to see if we could stay on schedule, and would either warn groups responsible for later phases of the project that they might be pressed for time or would inform stakeholders early that a schedule change might be necessary. This allowed everyone to make the adjustments necessary to make the project run smoothly.
"Mike" was also a very organized person. At the beginning of every project, he would ask for all the steps that needed to be accomplished to get a project completed, and he would put each of those steps into a spreadsheet. Mike was great at scheduling meetings and getting our questions answered. He didn't really understand what we did, though. We had frequent meetings that had no purpose other than for us to keep him in the loop as to the changes in the project, which for the rest of us was a waste of time. He also could not tell the difference between issues that were merely annoyances and the ones that were truly problems, so he treated them all with the same urgency. Mike was very good, however, at keeping everyone in the loop about the status of the project at any given time.
Yes, Beth is a better project manager than Mike. But Mike met the expectations of the company we were both working for at the time. Why? He was able to schedule meetings, facilitate communication, run reports, and inform the right stakeholders what the status of the project was. But since a true manager should help make processes run more smoothly and remove roadblocks for the team, Mike couldn't be called a manager. Thanks to one of my MBA instructors, I have a term for Mike's job, and it is a project administrator.
So circling back to the question of who really should be leading projects, I'd point out that neither Beth nor Mike led every aspect of their projects. IT personnel often forget about the fact that while software delivery is important, so is managing the other changes (whether culture changes for internal software or marketing efforts for external software) necessary for project success. Both Mike and Beth focused only on the implementation and delivery. So regardless of whether you have a project manager or project administrator, you need to have a leader preparing the business for the change. (I have more to say on that subject, but it will have to wait for another blog post.)
Is it appropriate to have a project manager lead the implementation portion? If your project manager is really a project administrator with a different title, then no, absolutely not. Most project administrators I've met don't really manage or lead - they merely create reports. Projects that aren't managed or led very well will almost certainly fail. When all you have is a project administrator, you must hope that you have a strong software architect that will assume the responsibility for leading the project. If so, the project still won't be run effectively or efficiently, but it will get done.
What about a true project manager? Keep in mind that a project manager's job is to manage a project, not to lead it. Unless the project manager has either deep subject matter expertise in the content of the software or significant experience with delivery, he or she will be unable to truly lead the project. It is common in these scenarios to ask the primary business stakeholder to lead the project through its inevitable issues. It is possible for a team to manage itself well through process and communication, but describing how that would work will have to wait until next month.
July: Is a project manager the right person to put in charge of your software project?
October: Getting programmers to see the value in management
November: The Peter Principle and software architects
December: Creating a leadership team to make your software project a success
No comments:
Post a Comment