Friday, April 23, 2010
The Product Management Team
The control center for the transformation project is driven by a Product Management Team or PMT (a “product” in this context, need not be something your company will necessarily sell to the outside world. A product can be any specific project deliverable). The PMT should be the official technology touch point for business requests and should have the ability to refine those requests via use of business analysis processes, estimate the cost of the effort, and prioritize the potential work versus other commitments. Obviously, the product management team needs to work in line with the architecture and development teams in order to articulate the appropriate response to the requirements.
Having product management to also help with administer the project plans will provide this team with the needed visibility to assess urgent tactical requests. Items to consider for tactical requests are:
1. Is the request simple enough for the tactical group to handle? In other words, the request should not divert resources from the transformation project.
2. If the request is somewhat complex and the tactical group will institute a stop-gap solution, how will the transformation team ensure that the requested feature or functionality will be present in the strategic deliverable?
3. If the request is fairly complex and delivering under the legacy scheme is not cost-effective, how should the request be handled vis-à-vis the transformation activity? In this case, negotiations with the business group should prioritize the request against other expected transformation deliverables as well as assessing the impact on the transformation plan.
Notice that I have resisted using the more traditional term “Project Management Office” (PMO) to refer to this group. I believe this term and governance have emerged from a perspective where project management can be performed by anyone who’s “smart enough”, regardless of specific subject matter expertise. Take for instance the popular “Apprentice” TV Show in which Donald Trump assigns the contestants to “project manage” an activity challenge and then fires the person who, in his opinion, has performed the assignment least effectively. Perhaps this concept works for TV shows, but in the real world of software and systems development the manager responsible for the project had better be someone who understands the technology and has an understanding of the team skills involved in the project. The manager of an IT transformation project cannot have only an administrative function.
I recommend that the actual management of a deliverable be assigned to the appropriate technology manager and not to a generic “project manager”. Instead, the Product Management Team should be seen as the facilitator and enabler for the actual project work conducted by a solution delivery manager. The PMT can have a direct role in specific project related activities: Business Analysis, Project justification and Initiation, Project Planning, Project Tracking, Vendor Relationship Management, Quality Assurance, Implementation and Migration Planning, etc. and should act as a coordinating umbrella for a Project Management Steering Board that includes representation from all other constituencies as well: development, business, finance and operations.
Speaking in practical terms, a key area of friction to watch out for from this team is in delineating a clear line of responsibility for the person who will ultimately be accountable for a project deliverable. The reasons I advise against using the term “Project Management” for this role are: The term “Project Management” naturally implies this entity is responsible for managing the project and thus ultimately empowered to make project-level decisions. If in fact, this group is managing the project then there is no issue, but what often occurs is that the actual project execution is driven by the Development Manager. The term “Project Management” obscures the line of responsibility and causes confusion and tension. Secondly the term “Project Management” does not properly encompass the other areas of responsibility that this function should have: business requirement gathering, lifecycle administration, project communications and tracking, assisting in defining the overall product delivery strategy and ultimately enabling the project delivery.
From an organizational viewpoint, the project coordinator attached to a specific project should have a dual reporting line to the actual delivery manager as well as to the product manager director. The interaction with the former should be both daily and intense since it relates to the minute-by-minute project activities, while the later should only be on a periodic basis for overall status reporting and to receive overall direction regarding project tracking standards and processes. Yes, the reporting of the status may “blow the whistle” on project issues that require the Product Manager to validate the actual health of the project with the Delivery Manager. This should occur in the spirit of “check-and-balances” and should not be seen as empowering the Product Manager with actual supervisory or executive authority over the development team. In any case, there should be proper procedures that allow any conflict between the Product Manager and the Delivery Manager to be escalated to their respective managers for resolution.
No one ever said life wasn’t complicated!