While reading various articles in Information Management, I came across an article that has some direct implications to projects that I have seen managed in the past. I often see the development teams applying Agile practices, yet the project management team often does not know how best to “Manage” the Agile development process or teams (I have also seen the development team managing/driving the business, but that is a different thread.)
In the article “Project Portfolio Management Best Practices in Agile Software Development” by Mark Kromer, Mark does a good job as he describes the role of a Portfolio Manager to ensure that the projects align with the corporate objectives, meet the budgets, and ensure that value is returned to the business, while allowing the development teams to operate within their sprints and develop the required solutions.
There still is a line of separation, although blurred, between the project management and the Agile development team. This is where the struggles often come in. The development teams typically want to start and find their way along to the solution and do not want to analyze the overarching set of requirements, architecture, risks and alignment with other projects. As the article points out, it is this area where the portfolio manager needs to ensure that all areas of the requirements, scope, and overall objectives are defined, with identifiable tracking metrics, prior to moving forward. It is in this critical area that the executive stakeholders of the projects will ask all of the questions.
This article touches on organizational structure recommendations, in that the grouping of projects together under a single management structure can permit the control of the scope, cost, and allocation of the resources across multiple initiatives. In addition, by managing all of these portfolios under a single PMO, this approach permits the business to obtain feedback from the Portfolio Manager and make decisions as to what initiatives are worthy of funding versus being pet projects. In addition, by identifying the metrics by which these projects will be measured at the start, all team members will have clear expectations of how they and their project will be evaluated.
The information in this article is all common sense, yet without focus on the organizational and reporting structures and processes (yes there needs to be some even with Agile), projects are often not set up to be as effective as they could be. As with most projects, technology is the easy part, ensuring the people in the organization are set up to succeed, is hard.
