Table of Contents
- Inventory current systems
- Plan portfolio and programs
- Manage portfolio
- Manage programs
- Manage contracts
- Manage enterprise risk
The high-level workflow for this discipline is shown in Figure 1 and the detailed amalgamated workflow in Figure 2. The first two activities, Inventory Current Systems and Plan Portfolio and Programs, are periodic, but the remaining four can be almost daily activities depending upon your organization. An important message of this discipline is that in order for it to succeed your organization must be as agile as possible: it is possible for enterprise-level professionals to work in an agile manner, but they must choose to do so and be allowed to do so. Furthermore, portfolio management activities are an important part of “iteration -1” of the agile lifecycle.
Before creating a portfolio plan, you must take an inventory of the current systems (sometimes called assets) within the enterprise. The goal of this activity is to find out what exists already in the enterprise, as well as what is currently being worked on: this helps define the scope of what is planned versus what is in progress. Every system, from the “side projects” to mission-critical enterprise systems, should be identified. This often is easier said than done; however, it can be as simple as creating a checklist of projects and programs, to bringing in a third party vendor to assess the situation and give you a detailed report of their findings.
The planning cycle, depicted in Figure 3, in most organizations typically takes place on a yearly or quarterly basis (although continuous planning can be much more effective for high-maturity organizations). It is important to plan your portfolio because without a plan in place to meet the business objectives, you cannot accurately align programs and projects to meet the strategic needs of the enterprise.
Monitoring of existing projects is an important aspect of portfolio/program management. This may require flexibility on the part of the portfolio manager because the various project teams may follow one of a variety of software development methodologies. The individual teams may follow the RUP, XP, FDD, or many other methods. The teams may vary at the level of their project management methodology, for example some teams may follow a Project Management Institute (PMI) style approach whereas others may prefer Scrum.
Interdependencies between projects should be identified, understood, and accepted within the portfolio in order to ensure the delivery of systems that meet the overall business objectives of the organization. The interdependencies can include deliverables such as common architectures (which may emerge when the plan comes together), important release dates, arrival of new infrastructure hardware, plans for database or other system upgrades, or a myriad of other project related issues. You can also take this time to identify overlapping or redundant resource dependencies and skills. Another benefit is that people can synchronize their activities between projects and even programs.
You may also need to define any program(s) and corresponding program plans. To define a program, you need to go through the process of identifying the related projects and put them together in a program. A program plan defines the strategy for implementing the similar or related projects in a program in the most efficient manner possible. This plan also helps show the portfolio manager the dependencies between the other programs and projects being run outside of a program.
Finally, your Enterprise Change Control Board (ECCB) is responsible for reviewing any incoming change requests, including both enhancements and defects. The first step focuses on triage, where high severity defects are assigned to the support team so that they can be dealt with by a hot fix. Lower severity defects and all enhancement requests will be evaluated by the board in order to determine which change requests are to be acted upon and which systems will be affected so that the change request may be assigned appropriately. This is where enterprise change management differs from the single system change management covered by the Configuration and Change Management (C&CM) discipline within the RUP. The change request is either processed appropriately by the individual project team in the case of systems currently being worked on or is put into a queue for future consideration.
The portfolio manager executes to the portfolio plan. Projects that fall outside the scope of a program are initiated as part of this activity; otherwise they are initiated within the scope of program management. The initial version of the vision document is created by the portfolio manager; quite possibly this could be in bullet point form. The only way to get projects funded is to make sure the project’s outcome adds to the business goals. A funded project should then get added to the portfolio plan so that it can be monitored. From the point of view of the RUP this is “pre-Inception” work to get the project underway: there is an implicit assumption within the RUP that this work occurs, the EUP makes it explicit.
Things change, so the portfolio manager must monitor the status of programs and projects. When the portfolio manager sees that two projects share the same goal, then either one project needs to be eliminated or the two projects need to be merged. This sort of problem shouldn’t occur if your portfolio management efforts are effective; therefore, you should identify how this situation happened and why. Also, if a program is dependent on some external project for functionality and that project runs into trouble, the main program will need to adjust accordingly.
The activities for this are very similar to the Manage Portfolio activities; however, although a program has a smaller scope and focus, it is often just as complex to manage as your entire portfolio. The main goal of program management is to manage a specific group of projects with similar scope and business goals. The main effort of initiating a project will happen here (or in Manage Portfolio), and then the program manager will monitor the project against the program plan. A key difference is that program reviews take place at regular intervals to monitor the progress of the program.
Vendor managers are responsible for identifying external contractors and awarding the contract at the end of the process, as depicted in Figure 4. Both the portfolio and vendor managers work together with the HR manager in monitoring the awarded contract from a different viewpoint. Each project or program within the portfolio requires different staffing levels. It’s interesting to note that although contract negotiation is a secondary concern according to the agile manifesto, the reality is that contract management is a very important part of effective portfolio management, which in turn is an important part of your overall strategy to scale agile software development.
The portfolio manager manages contracts, and the vendor relation manager administers the contractors on any given project. The portfolio manager can help the enterprise realize an increased business value by lowering contracting costs and increasing the overall productivity of your development and maintenance teams by managing the resources required across the various programs and projects. It is effective to organize the management of contracts for any staffing activity at the enterprise level because some projects can impact others and be multi-year in length. Efficiencies can be achieved by reducing duplication of effort (for example, contact with legal and strategic sourcing can be centralized), and service vendors are willing to give you substantial discounts on long-term and large contracts.
After a contract is awarded, both the portfolio and vendor managers must monitor its progress when project managers acquire staff and other resources. Although project managers are ultimately responsible for managing how subcontractors are used on a daily basis, the portfolio manager is responsible for managing the overall relationship with the contracting organization(s). The portfolio manager should work with the various program and project managers to ensure that all the enterprise issues are being handled and addressed.
Risk needs to be managed at the enterprise level in order to discover any potential problems with meeting the strategic business goals of your organization. Just as project managers are responsible for managing project risk, portfolio managers are responsible for managing portfolio risk. Portfolio risk, often referred to as enterprise-level risk, is the aggregated risk of all the different smaller risks at the program and project level that can literally kill successful implementations.
Each project (when looked at solely from the project perspective) may be low risk, but when examined from a portfolio perspective, all of the projects combined can pose high risk to your organization. For example, if your organization is a COBOL shop running mission-critical systems, a good majority of your staff may be nearing retirement. Another example is basing all your projects on a new development platform or technology: if that technology or platform fails in the marketplace, so may your entire program. To help mitigate portfolio risk, the portfolio manager may need to help the program and project managers see how their specific project deliverables relate to the overall picture of the enterprise.