What would a project portfolio look like in an agile software development organization? In traditional waterfall and iterative software development scenarios (such as RUP), portfolio management is an early part of that process to determine project selection criteria, alignment to strategic direction and to monitor program status during development. Project portfolio management is a practice that is strategic, high-level and should be planned out before developing requirements or code for a new product with a focus on costs, benefits and ROI. But in a software organization that is aligned to the Agile manifesto, attention moves away from complex processes up-front in the project cycle where product development is a more natural part of the customer value proposition with the ability to modify scope and the flexibility to change on the fly without a stringent change control mechanism. This means that project portfolio management plays a slightly different role in these organizations. But portfolio management can still play a vital role in project decision processes and controlling project budgets. Here we will examine the role that PPM plays in an agile development organization.

To illustrate an example of PPM in an agile software development organization, we’ll use the example of an internal software development organization in a large enterprise that serves different internal business units:

  • Fictitious organization: Super Duper Enterprises
  • Project: Develop a new meeting room management Web application to assist the entire enterprise of Super Duper Electronics in effectively booking meeting rooms anywhere in their multiple office locations. Currently, Super Electronics has many conference rooms that are booked ad hoc without a centralized mechanism to control reservations, resulting in double-booked conference rooms, inappropriate conference rooms based on the meeting need and underused space.
  • Program manager: Mike. He works in the IT program management office and is responsible for this project’s budget and quality as well as Web development program alignment to corporate strategy. He acts as the Scrum product owner with the business sponsors’ best interests in mind. [Note: Scrum is an iterative agile software development process with self-organizing teams made up of the Scrum team, a product owner and a Scrum Master. Typical Scrum team size is around 10 individuals.]
  • Project manager: Sally. She manages many projects at once and is responsible for requirements, scope and schedule for this project. She works in IT and works very closely with the business stakeholders and with the PMO team.
  • Development lead: Bala. He is responsible for managing the project within IT and works with Mike to ensure that the schedule and scope are met.
  • Executive sponsor: Dahlia. She is the executive VP of facilities at Super Duper Enterprises and is the key sponsor of this project. She has reserved the money to pay for this project from her budget.

A project portfolio manager is responsible for insuring that his or her projects align with the stated corporate objectives of that portfolio, that the proper value is being returned from those projects and that the budgets and benefits meet the limits established for that portfolio. Regardless of the methodology used by the software development team (Agile, waterfall, RUP, etc.), your organization should plan out strategy with one to two year multigenerational strategy plans. Many organizations with large, complex budgets and complicated funding sources will engage in long-range strategic plan more in the neighborhood of three to five years. The parameters for the portfolio will have been set at a planning meeting of executive sponsors. The portfolio manager must manage project budgets, deliverables and decisions based on those parameters.
In our example, let us assume that Mike, the program manager from the program management office, is ultimately responsible for all internal Web applications within IT, meaning that Mike is the portfolio manager for the project category called “Internal Web Apps,” which have their own budgets, resources, sponsors, etc. Since this new “meeting room” application falls within this portfolio and is in Mike’s sphere of influence, he will calculate expected returns and benefits from the project in terms of ROI and payback period. This effort of benefits and alignment analysis will occur in a software organization regardless of the methodologies used by the development team and should be performed during strategic planning cycles before any requirements analysis, specifications or development occurs. A set of key performance indicators will be established up front against which all projects within that portfolio will be managed and rolled up into a summary for the entire portfolio.

Mike will work with Bala, a manager within the development organization, to determine the availability of resources on his team and any needs that may exist to look for external sources to work on the project on contract. Any procurement of outside resources would need to roll up into the cost, risk and procurement analysis by Mike at the portfolio level for all development projects.

These factors have serious impact on the budget requirements for projects within an established portfolio. Not every organization operates the same in this regard. There are times when a budget has already been determined for projects based on portfolio analysis or predefined financing sources. In other instances, the project budget can be devised bottom-up from resource rates and costs derived from a project schedule, as opposed to top-down. This is where a distinct advantage of portfolio management surfaces. When examining projects grouped together for a specific set of objectives, using defined budgets and with an agreed-upon ROI, you can then control costs and resources across common projects. This will help you to determine which resources are actually available, their capacity and their utilization across the portfolio instead of in a more narrow project-specific definition. This way, Bala is able to communicate back to Sally which resources are actually shareable, working toward a common goal and will
likely have the skills needed for each project in that portfolio.

Once it has been established by the PMO that this “initiative” has sufficient funding, available resources and matches with the corporate strategies for a portfolio of Web development projects, the PMO hands responsibility to Sally, the Super Duper Enterprises project manager who will initiate the project. In an agile software development environment, similar to waterfall environments, this means she will reach out to the project stakeholders and key project participants to begin the process of creating plans for communication, organization, mission and risk. Once she works her way through the process, toward defining requirements, scheduling and activity sequencing, she will begin experiencing a departure from traditional large, complex project management and managing project teams in an agile environment. In many agile Scrum situations, the project manager updates progress and measures against a baseline that can be quite fluid. The product manager will liaison with the development team as the product owner
where product backlogs can be modified, particularly added to so as to include outstanding ideas from development. This is contrary to the Project Management Institute Project Management Body of Knowledge (PMI PMBOK) style of approvals, sign-offs, baselines and other stringent change control mechanisms. Don’t expect to follow those guidelines in an agile environment. But do not lose site of the management and monitoring of projects at the portfolio level so that you can detect budget or schedule overruns early and when necessary make course corrections as early as possible.

In traditional project teams where complex software development occurs, there will be a lot of effort put into upfront documentation at the outset and an attempt to capture all product requirements, capabilities and requests before any development work begins. In agile project teams, the sequence is a little different, with less emphasis on gathering all of the detailed documentation and requirements first. Agile product teams capture requirements for a “Sprint 0” to begin development work and then refine the requirements documentation iteratively throughout the process. Requirements and scope have flexibility, and the entire team involved with implementing the solution must be prepared for change. The objective of project portfolio management in software development, regardless of the development methodology, is to analyze all areas of investment, strategic objectives, resource availability and risk analysis before entering into the next product release cycles, new product development or other ventures. Bala
will want his team to begin their Sprint iterations as early as possible and it is important at this point that Mike, the program manager, conveys the importance of keeping to budget and schedule to the project manager, Sally, while she hands off product definition to the product managers and business analysts.

In these agile development scenarios, project planning and scheduling is minimized, while more effort around planning and scheduling is performed by the portfolio manager, Mike. But now that Bala’s team has begun executing against the product definition and iterations have begun, it is critical that Sally reports the progress up to Mike and to the key stakeholders, such as Dahlia, the executive sponsor. This is where PMBOK standards come in. For staffing plans and communications plans, it is important for a project manager to have early buy-in during planning, before execution. In agile environments, a portfolio manager, similar to Mike’s role as program manager, will utilize the PMI best practices around financial analysis and investment criteria such as calculating and understanding ROI, internal rate of return, net present value and payback period on projects in order to demonstrate project success from more than a cost and schedule perspective. This way, projects can demonstrate organizational value while also comparing the return against the investment (cash flow analysis). From a portfolio analysis perspective, PMI suggests rolling projects together into portfolios to analyze return and costs from high-level strategic objectives as opposed to only project-level objectives.

In the process of doing so, the portfolio manager will avoid the large documentation requirements that lock-in detailed baseline plans upfront. Instead, an agile portfolio manager would ensure that the projects in his portfolios remain flexible and cognizant that change will need to be manage during iterations, making scope lockdowns impossible during the planning phase.

As you embark on new agile development projects, you should consider maintaining management and monitoring of these efforts with a budgeting, analysis and justification process, which I have classified here as project portfolio management. There are a few best practices to keep in mind as you begin building out your portfolios:

1. Manage your projects from a summarized portfolio level with KPIs that answer these basic questions:

  1. Why are we embarking on this effort?
  2. How much will it cost?
  3. Do we have the resources for it?
  4. What is the return on the investment?
  5. Does it align to our business objectives?
  6. Will it meet our quality standards?

2. Determine the ranking of your portfolios based on strategic alignment, ROI, costs and  benefits.
3. Use an easily accessible portal system for reporting and share ongoing performance from a portfolio level that is a summary of project performance against each of your organization’s negotiated KPI metrics.

Often, I have seen companies succeed by utilizing technologies such as Microsoft SharePoint, Oracle Dashboards or middleware portal servers from IBM, Oracle or Sun. A common open source technology used for this purpose is Pentaho Dashboards. The intent is to make the dashboards, scorecards and portals easy to understand and easy to access and not to use a lot of project management terminology or statistics that will make general users uncomfortable accessing this information. To be effective, this site should give immediate feedback on the condition of projects, investments and portfolios and allow interactive drilldown for those users who wish to dive into the complexities of project performance reporting.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access