Overview

What is the price of missing critical project dates?

Who is accountable for all everything coming together at the right time for all projects?

Can you identify and resolve potential delays in your portfolio of projects or the status of all your projects?

A Program or Project Management Office (PMO):

• Matches business goals with appropriate technology platform or solutions
• Provides centralized control of all projects under the program umbrella
• Reduces time to market
• Increases communication and coordination across all projects in your portfolio
• Provides increased resource utilization across the organization and matches skills to project needs
• Manages and enforces project priorities
• Manages and controls scope, change, cost, risk, and quality across all projects
• Provides increased Client Satisfaction with project related work and operational support:
• One place to go for all project status and communication
• Support staff for project services
• Reduced project costs because common tasks could be managed at PMO level

When to Use a Project/Program Office

Create and maintain a Program Management Office if:

• Conditions or scope is changing throughout the project - extra expertise is necessary to manage this change
• Multiple contractors are selected via a bid process - clearly defined scope is necessary prior to contractor expertise being on board; pre-qualification of contractors is critical
• Multiple contractors are necessary because of the complexity or size of the project - a single contractor does not have all the expertise to do the work and management of multiple contractors requires a centralized view of the solution.
• Design and implementation are done by separate contractors
• The client organization is diverse and may be difficult to get cooperation unless they are actively managed
• Time to market - Whenever time to market is a critical factor in completing the project
• Multiple vendors - Whenever there are multiple vendors or services for a given project or program
• Diverse geographic locations - Whenever the solution is being implemented across diverse geographic locations
• Limited resources - Whenever limited resources need to accomplish multiple tasks
• Multiple projects - Whenever you have multiple projects under the same program umbrella or multiple initiatives utilizing the same resources

PMO Advantages

Designing and implementing projects in today's environment or even managing change in today's environment is more complex than ever before.  With multiple vendors, as well as a diverse range of partnerships and alliances, today's project landscape is as complex as it has ever been.  Trying to manage multiple projects for the same program initiative adds more complexity to the management team.  Unresolved issues can delay projects for weeks and months, which can turn into lost revenue, a lost competitive advantage, and an unhappy client.

A dedicated PMO provides the oversight to deliver your projects on time and on budget by managing your schedule, scope, and resources while watching the cost and quality across the whole portfolio.  The PMO provides expertise tailored to your business requirements while taking responsibility for all projects included in your portfolio or program.  A PMO provides the extra focus and resources complex projects demand.

The main focus of the PMO is to coordinate multiple projects under the Program/Portfolio umbrella and be the center of excellence supporting project managers in the implementation of the functions required to achieve successful projects.  The PMO is staffed by project and program professionals and will consolidate project resource plans, financials reporting, project schedules, change, risk and quality information into master documents to deliver your projects on time and on budget; directing and monitoring the projects to ensure quality; and disseminating project information.  The PMO offers project management tools, support, mentoring, project portfolio management, and quality assurance.  The Project/Program Management Office provides economies of scale not found in a single project team and offers a single point of contact for all information on the projects under the program umbrella.

The PMO helps to keep critical projects on time and within the budget by providing accountability at every stage, from initiation to acceptance.  PMO personnel identify and resolve common issues before they add time to already short time to market pressures.  The PMO provides expertise tailored to your business requirements along with the extra focus and resources complex projects demand helping maintain project momentum by contributing in these areas:

Consolidated Administrative Support - PMO personnel can make the lives of project team members easier by assuming administrative chores for project scheduling, report production and distribution, project management software operation, and maintaining the project/program/portfolio "War Room" along with common documents.  The PMO receives, consolidates, and distributes information for all projects under the program/portfolio umbrella. 

Providing Project Management Consulting and Mentoring - The PMO will oversee the operations of each individual project and project manager; offering mentoring, support, and training as needed. 

Resource Allocation - With limited resources, it is critical to have the right people at the right place doing the right jobs.  The PMO is in a position to assign project managers and project team members matching needs with specialized skills, availability, and geographic needs as well as balance the workload of project managers.  By doing so, the PMO ensures resources are being used efficiently throughout all projects under the umbrella of the program/portfolio.

Vendor Management - Many details need special attention when purchasing hardware, software, and services from any vendor.  The PMO provides objective accountability to identify and resolve issues that can delay the specification and delivery of the project.

Formation of a PMO

In a number of cases, the PMO is both a physical location and project personnel.  To start a PMO, the company officer responsible for project delivery will have to select an individual or individuals capable of:

• Managing and tracking multiple projects at the same time
• Training, mentoring, and coaching project managers
• Communicating on all levels of project delivery
• Managing and negotiating with contractors

Additionally, it is recommended a company set aside a physical location or "War Room" to be used for the PMO.  The room should be set up to accommodate the tracking and management of information such as whiteboards to allow the posting and tracking of project schedules, financials, and resource schedules. 

A web-based Virtual PMO or other collaborative workspace should be implemented to allow the project teams to collaborate.  At minimum, the web-based solution should have:

• A common calendar to communicate important project dates
• A master project set up with all project templates and processes which can be duplicated for each project
• A project documentation library allowing project team members to update and share information
• An area to post and update project tasks.  In many cases, it is advantageous to allow import and export from an external project-scheduling tool.
• The collaborative workspace would also allow PMO personnel to consolidate the information from multiple projects, provide mentoring for improvement, and highlight best practices or other noteworthy items. 
• Utilizing an Executive Information System front-end into the collaborative workspace could provide real-time status on all active projects to company and/or client management.

Steps for PMO Creation

1.       Charter the PMO.

It is critical to be very clear concerning the purpose and goals of any PMO. This should not be taken for granted. It should be determined in a workshop with the stakeholders if necessary. While the purpose of the business initiative being supported must be understood, the specific charter for the PMO itself must be documented and agreed upon as well. What is the authority of the PMO? What is it expected to accomplish? How will it be measured and by what process?

2.       Identify and define desired business benefits and measurement methods.

The PMO must understand the desired business benefits. How will success be measured?  In many cases, the business benefits are not understood well enough to be clearly documented. One of the functions of a PMO is to ensure that the targeted business benefits are clearly documented, agreed among the stakeholders and communicated to all concerned. To accomplish this may require workshops designed to get all stakeholders to align on the same set of objectives. A means of gathering, measuring, evaluating and reporting metrics related to business benefits must also be defined. 

3.       Define governance structure.
The need for governance is one of the best reasons to institute a PMO. Very often the strongest rules of governance related to a business initiative will be found within a PMO. Some of the questions are -- How will the PMO be organized? How will the PMO interact with the operational and developmental functions in the organization? What will the reporting structure look like? Who will be responsible to whom? What reporting processes will be used for status and progress reporting? Where will the PMO itself report? In some cases the PMO reports to a steering committee. In other cases it might report to the board. It's of critical importance to spell this out during PMO set-up.

4.       Define the impact management process.
The process for management, tracking and resolution of issues, impacts, changes and risks must be established. This will include information gathering and reporting, a means for defining when these events have occurred, escalation paths, reporting and the means for resolution and mitigation as well.  A clearly defined document storage process must be set up and communicated to all stakeholders. 

5.       Define leadership and communications protocols.
Governance is focused on management. Leadership is related to keeping the vision and purpose of the PMO in mind through constant communication regarding both a reiteration of purpose as well as clear communication as change occurs. In setting up a PMO the means of communication and the leadership principles that will be applied must be defined. How will change be communicated, and the decisions related to change be executed? Who will be responsible to keep the vision and direction that should drive the PMO constantly in everyone's mind? 

6.       Define portfolio/program wide risks and develop mitigation strategy.
Known risks associated with the initiative and a means for mitigating them must be documented as part of set-up. Once the PMO is under way, risk management is a function of impact management.

7.       Define Change Control strategy

All projects under the control of the PMO should manage change in the same way and all change control documents should be coordinated by the PMO.  The PMO Director should be a member of the Change Control Board, reviewing all changes submitted for approval.

8.       Define project support function.
The projects within the PMO will require support so that methods, tools and procedures can be used in a uniform manner and economies of scale can be achieved. This function by itself is of tremendous value and is sometimes mistaken for the PMO function itself. In any case, project support is an important aspect of a PMO.

9.       Define integration approach and methods.
The means of managing and integrating each of the streams of work required to achieve the business objective and deliver the business benefits of the initiatives the PMO is supporting must be defined. If the initiative is to be supported by many projects, a master schedule of all the projects and their dependencies must be maintained, for example. How this will be accomplished on a day-to-day basis must be defined and communicated to all stakeholders and managers within the initiative and PMO.  The PMO should set the ground rules for the project management methodology and templates to be used during project implementation; and should maintain them as part of their charter. 

10.   Get Started!

• Hire the PMO Director
• Set up the web-based PMO and the physical space if needed
• Agree on the project management methodology and templates to be used
• Create the training course
• Train all project team members in the process, the collaborative workspace, the methodology, and the templates
• Start managing all projects with the methodology as a guide and use the collaborative workspace
• Coach and mentor project teams
• Consolidate all project documentations into PMO documentation

Using all processes and tools available for Resource Management in Daptiv PPM, the following process flow can be accomplished.  Output from any area of resource management from planning through actuals can be created using the Cross-Tab report in Daptiv Work Intelligence (WI).

The process can be modified if an organization doesn’t want to use all functions of the Daptiv PPM Resource Management.  For instance, if an organization doesn’t have a defined resource manager role, the team can be created using the Build from Enterprise function of the project Members application.  Once the team is created, the team can be assigned (scheduled) to tasks.  Using the Resource Utilization view or a WI report, management or the PMO Analyst can see the scheduled hours and move those hours by role into the Planned area.  As actuals become available, all figures can be viewed in a WI cross-tab report by period.

 

There seem to be a couple of immutable truths in the PMO world, especially in IT departments. First, there is always more work than can possibly be done. This usually surfaces in the form of an insatiable appetite for projects. Second, no matter how you prioritize the work, someone's going to be unhappy - and they'll try to make your life miserable by becoming the squeakiest wheel in the company.

 

The answer, as we PMO practitioners all know, is to elevate the prioritization decisions up to the company executives. This usually means some sort of cross-functional steering committee or other governing body. It's great theory, with one major flaw. Those execs don't readily participate. I can't count the number of poorly attended steering committee meetings I've run across. The execs either don't show or send a lower ranking delegate not empowered to make decisions. Which leaves the steering committee pretty powerless, and results in the CIO once again making the decisions. And once again taking the heat.

 

So, how do you get these all-too-busy executives to pay attention and take responsibility for prioritization? The best process I've found is what I call "shock therapy for the executive team", and it involves three steps: Presentation, Argument, and Decision Time.

 

Step 1: Present the problem. This is all about making the problem obvious. During one of my CIO stints, we were creating a new IT infrastructure from scratch. This, of course, involved many parallel projects that could not possibly all be run in parallel. So, I formed an project steering committee and invited all the VPs. All but a few sent delegates, and we made no decisions.

 

Fine. So I put together a picture of the entire architecture, detailed in big blocks the major pieces, there costs, effort, and timelines and presented this big picture to the corporate executive team at the monthly monthly meetings. I showed them the millions in costs, all the projects going live in the same month, and the amount of resources (double what we had on hand) required to get the job done. The CTO, who ran the product development group, took one look and said

 

 "Dave - if I were running this, there's no way I could do all of this at once. What are you going to do? How will you prioritize this?"

 

My response: "That's why I'm here".

 

Which lead immediately to Step 2: Argument.

 

First, the VP of professional services demanded that his CRM piece was critical and had to go live ASAP. To which the VP of Sales argued that if the SFA system wasn't put in place first, Sales would get stuck and Services would have nothing to do anyway! As you can imagine, each VP argued for there piece of the pie.

 

Which finally leads to Step 3: Decision Time.

 

I've written before about the use of various prioritization tools, such as scorecards, strategic alignment, etc. Here is where those tools finally come into play. They allow the executives, once they settle down, to look at some objective analysis to help them figure out which projects should come first. Whether that importance is based on fit to corporate strategy or critical operational needs, these tools are meant to be informative, not conclusive. You will also want to present any project interdependencies at this stage.

 

In the case above, the Exec Team quickly realized that some core processes were in dire need of automation, and that the ERP system was also the core of the architecture. Therefore, projects relating to ERP came first. The other VPs then understood why they had to wait. Even better, I was asked to present progress and new initiatives quarterly so we could decide as a body how to proceed. Note that in this case, we never even formed a Steering Committee. The Executive Team ended up taking responsibility directly!

 

I have seen this process work repeatedly, and the steps to "shock therapy" tend to follow the same pattern:

 

1 - Shock them with the enormity of the problem. And do it with graphics and simple numbers, not long lists of individual projects. If they get lost in the details here you'll be back at square one.

 

2 - Let them argue for a while. As they struggle with the problem they will realize this is way too important to delegate to their underlings, the CIO, or the PMO. They will realize these are truly strategic decisions - that's their job and they know it.

 

3 - Provide them with the information they need make these decisions. This information varies, of course, by company. So, you'll have to work with your Exec Team to figure what information is most effective.

 

And good luck - while this is easy to write about, it's no cake walk to execute. You'll be relying heavily on the relationships you've built with each executive (you have done that - right?) to see you through this process!

eProject is going to put on a User Conference in Seattle soon and we want your input for ideas for sessions, breakouts, or expert advice.  Please respond to this blog with ideas. 

I don't remember where I got this, but the guidelines are very logical and sensible. 

This guide outlines the factors that should be considered in the selection of a software package and its associated hardware. It indicates the steps that should be taken in the evaluation processes and possible sources of help.

Section One: Objectives
Section Two: Costs
Section Three: The Requirements Specification
Section Four: Who to Approach
Section Five: Evaluating the Alternatives

Section One: Objectives

The introduction of a new software package is a costly and time consuming exercise and it is therefore important that the reasons for the acquisition and the benefit that it is expected to achieve are considered and documented. A written statement of objectives will help to define the scope of the project and can be used to evaluate its success on completion.

Section Two: Costs

It is essential that the full cost of the project is assessed. This is likely to be considerably more than the initial purchase cost of the software and should include the initial costs, the on-going support costs and perhaps also the cost of expanding the system over a period of time. Items that may need to be considered are as follows.

Hardware purchase

This may include hardware for the central software/database, network hardware and desktop hardware for the users. University standards should be followed and the availability of discount purchase arrangements considered. Compatibility with other campus equipment and the availability of campus expertise and maintenance should also be considered as a priority.

Hardware maintenance

Provision must be made for a suitable level of hardware maintenance. Desktop equipment can normally be maintained under the Campus Maintenance contract administered by Computing Services. Central servers and specialist equipment will need specific arrangements either via existing campus contracts or through the supplier or manufacturer. Most equipment will come with a warranty period providing free cover, but it is important to consider whether the free service provides a fast enough response.

For very critical systems it may be necessary to invest in extra equipment to provide resilience in the case of any failure.

Software License

Apart from the application itself there may be a need for database software, reporting software, backup software and other system management software. University standards should be followed and questions of compatibility, sharing of support expertise and the availability of discount purchase schemes should be considered.

Software is licensed in many different ways. Common ones are 'per concurrent user', where the license allows up to a pre-set number of people to use the software at any one time, 'per registered user' which requires a license payment for every user who will ever use the system, 'site-license' which generally gives unrestricted access throughout the organization, but sometimes has limitations imposed.

A license may be for a fixed period or perpetual. However even if it is perpetual it is not uncommon for suppliers to redevelop their package from time to time and to treat it as a new product requiring a new license fee.

Software support

Provision must be made for a suitable level of software support. A support contract will normally provide a Help Service, a software error fixing service and upgrades of the software from time to time. The cost is often a percentage of the license cost, 15% being about average, but 20% not uncommon.

If the systems is liable to be affected by statutory changes (e.g. income tax or VAT), or other mandatory changes outside your control (e.g. national statistical returns), you should ascertain whether these will be provided free of charge under the contract.

Implementation

There will be specific costs associated with implementing the system. These include training and consultancy on how to set it up to suit your needs. There will also be the cost of loading the initial data, either by converting it from an earlier system or by entering it manually. If the system needs to interface with other systems there may be costs in developing the necessary software or acquiring the necessary hardware.

Computer systems take a considerable amount of effort to implement so there will be a cost in staff time and there may be a need for extra temporary help during the project.

Operation and Administration

Computer systems require on-going operating, administration and housekeeping activities and consideration needs to be given as to who will carry out these duties. Examples are setting up security facilities, registering new users, taking regular backups, monitoring and reorganizing the database to avoid file overflows and to maintain performance.

Some of these activities may be carried out by non-specialist staff with suitable aptitude and training. Others will require specialist technical expertise. If this is not available in the department then arrangements will need to be made with another department, IT Services, the software supplier or a third party.

Upgrades and developments

Upgrades should be provided under the maintenance agreements, but suppliers may charge for the installation of the upgrade, and there will be work in testing any new software before it is implemented on a live system.

Development of the software to meet changing needs may or may not be covered by the support agreement. A supplier who wishes to maintain a position in the market will normally wish to keep the package up to date, but specific needs that may arise for a specific customer are likely to be chargeable. Some suppliers may only provide a standard package and may decline to make specific changes for a single customer.

Section Three: The Requirements Specification

It is advisable to produce a written statement of your requirements. This will help prospective suppliers to produce suitable proposals and will help you to evaluate the alternative options. It can also become part of the contract that is eventually agreed with the chosen supplier. Suppliers should be asked to provide a written response to the specification.

The areas that should be covered in a Requirements Specification are outlined below, and examples of such documents are available in IT Services.

Set the scene

Tell the prospective suppliers a little about your department, who you are and what you do. Say why you are looking to acquire or replace the computer system, and how this system fits with other systems both within your department and beyond.

Functionality

Specify what you want the system to do. It is a good idea to classify requirements into essential items, desirable items and requests for information. For example on the question of charging for issues from stock you might want to say the system must use average pricing for stock issues, or it is desirable that the system can use latest pricing, or simply ask 'which methods of stock pricing are available?'.

When selecting packages for common requirements in widespread use, for example a Stores system, it is better to concentrate on specifying areas where your needs may be non-standard, rather than stating basic functionality where the answer from all suppliers will be yes.

General Features

General facilities to be provided by the package should also be specified. These include:

• Reporting and printing facilities.
• Screen handling facilities, i.e. the ways in which it is possible to move between screens and between records either randomly or in pre-set sequences.
• On-line help facilities.
• Security, e.g. limiting groups of users to specific screens, data or functions and the availability of suitable audit facilities.
• Backup, recovery and housekeeping facilities.
• Archiving, i.e. facilities to move old data out of the current files, but still retain access as necessary.
• Customization facilities, and, if available, how software upgrades are affected.

Operating Environment

This section should specify what type of hardware, operating software and database the package must use, or ask what alternatives are available. University standards should be followed and advice can be obtained from IT Services. Local and wider area networking requirements should also be considered.

Documentation and Source Code

The supplier should be asked what documentation is provided with the package and whether the source coded is provided.

The source code is needed for a programmer to make changes to the system. It can be useful to have the source code of any reports provided as part of the system, as it may then be possible to copy and adapt them for other reporting purposes. It is not advisable to attempt to alter any processes within the system as this can easily lead to errors which will not be covered by the maintenance agreement. Even the adaptation of reports needs to be carried out with caution and may need to be re-worked when a new release is installed.

If source code is not provided (which is the norm), it is advisable to consider taking out an escrow agreement. This is an agreement for the source code to be lodged with a third party such as a bank or the National Computing Centre. In the event that the supplier ceases to trade the source code is made available to the customers and may enable them to make other support arrangements.

Installation, Implementation and Training

Ask the supplier what assistance they will provide and what training will be required. Obtain costs for all these services.

Contractual Information

Ask the supplier to provide a copy of their licence agreement and maintenance contract. Check on the level of service that they provide under the agreement, including:

• Does the agreement cover new releases of the product, how frequently, and are there any extra costs involved in installation.
• When is the help desk available and what response time is expected.
• Whether on-site assistance is provided, and whether this costs extra.

Company Details

Ask for details about the company, for example its size, number of customers, market share, and length of time in business. Ask them about their future plans and objectives to ensure that the package will move forward in a way that suits your plans.

Ask the supplier to provide a copy of their annual accounts for the last two years.

It is also worth asking whether there is a user group and what role it plays in the development of the product.

For shortlisted packages the supplier should be asked to provide reference sites who can be consulted or visited to get a user view of the software.

Sizing and Performance

Provide the supplier with information on the current size of the system and any expected increase over say three or five years. This should include the number of users of the system and volumes of the main items held or processed, e.g. customers, orders, suppliers.

The supplier should be asked to give estimated hardware requirements and timings of critical items eg. major processes or on-line responses.

Section Four: Who to approach

Proposals for the supply of the system should be invited from a number of suppliers. For some applications the possible options will be very limited, for others the choice may be very large, making it difficult to know how to limit the evaluation exercise.

In drawing up a list of potential suppliers the following factors should be considered:

• Is a similar package already in use on campus - a register of applications is kept in IT Services.
• Is there an education agreement for a package - consult the CHEST directory and IT Services.
• Is such a package in use at other institutions - consult colleagues in other institutions and IT Services may also have information.
• If the package needs to operate closely with some existing software, can the suppliers of that software suggest any suitable suppliers.
• Consult the trade press (both the computing press and the subject/business area for which the package is required).
• Consult professional organizations in the appropriate field.
• Consider whether you want to go for a tried and tested market leader, or a new package which may be innovative but immature (the latter will have a high degree of risk and potentially a high cost in terms of testing, fixing and possible adverse business impact when problems arise).

Section Five: Evaluating the alternatives

Evaluation should normally include the following steps, though the sequence may vary and some stages may be iterative.

• Assess the suppliers' written response to the requirements specification, noting particularly how many 'essential' items they are unable to meet, and considering the answers to the requests for information.
• Arrange for a demonstration of the package by the suppliers. This can be used to clarify areas of uncertainty from the written proposal and to assess factors such as ease of use and the general 'look and feel' of the product. Try some 'hands on' use of the product. If possible try putting some of your own data through the system, testing specific processes that you consider critical.
• If necessary arrange follow up demos, or 'workshops' on specific aspects of the product.
• Arrange to visit a user site to see the product in action in a real environment. Ideally this should be a user who has a similar type of operation to your own. Question the user about the level of service and support that they receive.
• Contact some further users to find out if they have similar views and experiences.
• Carry out an assessment of the financial stability of the supplier. Assistance with this can be provided by the Finance Office.
• Collect together all the information gathered from these evaluations and consider how suitable the package and the company are for your current and future needs.
• Check the license and maintenance contract carefully and negotiate changes as necessary. IT Services and the Finance Office can provide advice and help.
• Negotiate a suitable staging of payments to allow the system to be proved to be satisfactory prior to final payment.  

The concept of "project portfolio management" has become popular as a way to manage business investments in the same way "financial portfolio management" has been a popular way to manage financial investments.  At a high-level, many of the same concepts are involved.  You have a limited amount of money to apply to your business.  You want to manage this money as a portfolio to maximize the overall value and to allow you to reach your goals.  A portfolio management process provides a way to select, prioritize, authorize, and manage all of the work in the organization including completed work, work in progress, and work approved for the future.  Project portfolio management helps you come up with the baseline used to measure how well you are managing the portfolio to meet the company's needs.

 

Project portfolio management is a process to ensure your company spends its scarce resources on the work of most value. If practiced throughout your company, it will help to ensure only the most valuable work is approved and managed across the entire enterprise. Organization leaders unsure of how their budgets are spent, and who cannot validate the work being funded is the most important, will find themselves under greater scrutiny and second-guessing the future.

 

In general, the value of utilizing a project portfolio management approach to managing your investments is as follows:

• Improved resource allocation. Too often today, bad projects squeeze scarce resources and do not allow more valuable projects to be executed. One critical step is for all departments to prioritize their own work; however this is only part of the process. True project portfolio management on a company-wide basis requires prioritization of work across the whole company. In addition to more effectively allocating labor, non-labor resources can be managed as well. Non-labor includes equipment, software, outsourced work, etc. For instance, just because you outsource a project and do not use your own labor, does not mean it should not be a part of the portfolio. The same prioritization process should take place with all of the resources proposed for the portfolio. 
• Improved scrutiny of work. Everyone has pet projects they want to get done. In some organizations, managers make their own funding decisions for their own work and they are not open to challenge and review. Portfolio management requires work to be approved by all the key stakeholders. The proposed work is open to more scrutiny since managers know when work is approved in one area, it removes funding for potential work in other areas. As stewards of the company money, senior management will now have a responsibility to review, approve, and execute the work that is absolutely the highest priority and of the highest value.
• More openness of the authorization process. Utilizing a project portfolio management process removes any clouds of secrecy on how work gets funded. The process allows everyone to propose work and ensures everyone knows the process used to ultimately authorize work.
• Less ambiguity in work authorization. The project portfolio management planning process provides criteria for evaluating work more consistently making it easier to compare work on an apples-to-apples basis and do a better job in ensuring the authorized work is valuable, aligned and balanced.  Selecting and chartering a Governance Committee or a Project Selection Board, publishing their roles and responsibilities, and publishing the prioritization and selection criteria are all steps used to remove the ambiguity.
• Improved alignment of the work. In addition to making sure only high priority work is approved, project portfolio management also results in the work being aligned with the needs and strategy of the business. All portfolio management decisions are made within the overall context of the organization's strategy and goals providing a process for better translating business strategy into project investment decisions.
• Improved balance of work. In financial portfolio management, you make sure your resources are balanced appropriately between various financial instruments such as stocks, bonds, real estate, etc. Project portfolio management also looks to achieve a proper balance of work. When you first evaluate your current portfolio, for instance, you may find your projects are focused too heavily on cost cutting, and not enough on increasing revenue. You may find your portfolio is unbalanced with one type of solution focus or on new product development and not on the underlying infrastructure to sustain the development.  You might also find you cannot complete your strategic projects because you are spending too many resources supporting your old legacy systems. Portfolio management provides the perspective to categorize where you are spending resources and gives you a way to adjust the balance within the portfolio as needed.
• Changed focus from cost to investment. Financial portfolio management does not focus on costs, since the assumption is expenditures will result in the purchase of an asset (stocks, bonds, etc.) or a service (trading fee, investment advice, etc.). Likewise, when you manage your work as a portfolio, you change the emphasis from the costs of each initiative to the value provided. If the value (and alignment) is right, then the work will get authorized. If the value is not there, then the work should be eliminated, cut, or backlogged. This focus on value is especially appealing to the IT organization, which has traditionally been seen as a cost center rather than a profit center.
• Consistency.  Scrutiny should be applied to ROI statements and other future project claims to ensure realistic figures are being used and not just provided to ensure the approval and initiation of pet projects.  Using the process of project portfolio management, the review body will apply the same scrutiny consistently to all current and proposed projects. 
• Increased collaboration and communication. In many companies, senior managers make business decisions while only taking into account their own division. For instance, the Marketing Division is making the best decisions for marketing, Product Development is making the best decisions based on their needs, and the Finance Division is making the best decisions for finance. However, when all the plans are put together and use the same prioritization and selection process; they may not align into an integrated whole, and, in fact, they are sometimes at odds. You cannot perform project portfolio management within a vacuum. If you practice project portfolio management at the top of your company, all divisions will need to collaborate on an ongoing basis. If you are practicing project portfolio management within a service organization like IT, portfolio management will force collaboration between and among IT and the other client organizations. 
• Increased focus on when to "sell." When you are managing a financial portfolio, you may have investments that no longer meet your overall goals. The investment may no longer be profitable, or you may need to change your portfolio mix for the purposes of overall balance. In either case, you need to sell the investment. Likewise, when you are managing a portfolio of work, you are also managing the underlying portfolio of assets that the work represents. In the IT Division, for instance, the assets include business application systems, software, hardware, telecommunications, etc. As you look at your IT portfolio, you may recognize the need to "sell" assets. While the asset may not literally be sold, you may decide to retire or eliminate the asset. For example, you may have converted to new database software a number of years ago, and now you realize that only a couple more remain in use. It may make sense to proactively migrate the remaining old databases to the newer technology. This simplifies the technical environment and may also result in eliminating a software maintenance contract. This is equivalent to selling an asset that is no longer useful within the portfolio.
• Avoidance or elimination of work.  When looking at your project portfolio as a whole, you will now have the opportunity to avoid projects you may have thought perfect when looked at on their own or discontinue other projects not meeting your selection criteria.  Evaluating and re-evaluating all projects by the same objective criteria allowing your organization to discontinue those projects and reapply the finances and resources to more critical projects is a huge benefit of project portfolio management.  Portfolio metrics should be captured and shared with the rest of the organizations. A portfolio management dashboard should be created and shared. The business value of portfolio projects should also be measured and shared at all levels of the organization. 

The Process

Since you now know why project portfolio management is so important, let’s discuss how to go about creating the successful portfolio process for your company.  Project portfolio management is a repeatable process for planning, prioritizing, approving and executing work as a portfolio. You cannot start the planning and executing portions of the process without first understanding two fundamental areas. First, you need to define the nature and scope of the work you want to manage as a portfolio. Second, you must gain agreement on what is important to your organization so you have the context to make work prioritization and balancing decisions.  

The main sections of the project portfolio management process are as follows.

 

Definition

The definition step is where you define the terms and scope of your portfolios, and gain agreement on your basic portfolio model. For instance, you need to define information like:

• The organizations covered.  Will you include the entire company or just certain organizations?
• The type of work included.  Does your portfolio include projects, support, operations, maintenance, etc.?
• The categorization scheme. How you categorize your portfolio elements helps you balance your portfolio so you can optimize the overall allocation of resources. For instance, categories could include work supporting the business, growing the business, and leading the business. You could also categorize work as high, medium and low-risk, or perhaps global versus local categories.
• The balance points. For each categorization you define, you would also set some guidelines asto how you think the work should be balanced.
• The financial models. When it is time to prioritize the work, you want to make sure you choose projects aligned to your goals and strategies, as well as with the highest value. It is impossible to compare apples to apples if each project has different financial justification based on different models. You need to understand the financial models your organization wants to utilize and make sure all projects are justified using those models. 

When starting out, the Definition step may be a lengthy process.  As your portfolio management process matures, you will revisit and revalidate the definitions you have established since changes in emphasis will occur resulting in changes to the Definition. For instance, in the first year, you may decide to include only project work in the portfolio. In the second year, you may decide to include all other work categories as well and may result in changes to your categorization scheme. 

 

Foundation

You cannot make decisions on prioritizing work without knowing what the company or organization feels is important. The Foundation step results in establishing the context within which work priorities and approvals are made. Foundation starts with evaluating your environment through a Current State Assessment and then contrasting the current state with a Future State Vision describing where you want your organization to be in the future. The process culminates with the validation (or creation) of your mission, vision, strategy, goals and objectives. Your strategy and goals will provide the high-level direction for alignment and prioritization of all the work for the coming business cycle.

 

The Foundation step can be very lengthy, but at the same time, very valuable. The Current State Assessment may take a long time to complete.  In subsequent years, you will only need to recognize changes. For instance, your strategy and goals may change slightly to put new emphasis in a couple different areas and your Current State Assessment may need to be reviewed and updated.

 

Selection

The Selection Step is where all of the potential work is surfaced for the coming year. At this point, each request only needs to complete a simple Value Proposition document describing the work and the value it will provide to the organization. The Value Proposition will also show alignment with the overall organization strategy and goals. If you are including all work, the Value Propositions will include projects, support, discretionary, process improvement, and leadership work.

 

Prioritization

One of the key assumptions is there is much more work requested than the organization can execute in one year. (If, in fact, you could do everything requested, you might not need a prioritization process.) After all the work has been selected, a prioritization process begins. First, work is prioritized within each business unit and a more detailed Business Case is created for all projects surviving an initial internal cut. The Business Cases for all the remaining projects are then prioritized between all business units to come up with the final list of prioritized work. This process is easily described, but hard to accomplish because of the need for collaboration and consensus among senior managers.

 

Authorization

After the Prioritization step, the most valuable and aligned work is authorized for the coming year. This process sets aside approved budget and resources to complete the work. This is not a guarantee the work will be funded as changes in business conditions or newly surfaced work could bump some authorized work off the approved list; however, authorized work will be scheduled and executed in the coming year.  

 

Activation       

Activation is the process of actually scheduling and executing the work throughout the year. In the Activation step, managers and project manager build schedules to start and complete as much of the approved work as possible. Operations and support staff are in place at the start of the year and will be in place all year. Projects and leadership initiatives, however, need to be scheduled throughout the year based on business urgency and available staff.  Capacity planning is a key tool used during this step in order to have the staff on hand when needed for project planning and execution. 

 

The Activation step contains a mini-Business Plan Process to account for new work surfacing during the year. New work needs to be selected, prioritized and authorized objectively on par with current work. If new work is authorized, it may mean some work previously authorized will need to be canceled or delayed.

 

Activation also includes keeping track of old projects to track value metrics and life-cycle costs, as well as future work to ensure all the authorized work is scheduled appropriately based on business priorities and available staff.

There's an excellent article in CIO Magazine this month showing how A.G. Edwards reinvented its PMO to bring their projects to an 88% success rate (from about 50% originally).

Some key lessons:

• They created a 25-step project management high-level framework of just the high level activities common to all projects. They didn't inflict a detailed application development methodology and left the "how" flexible, as long as the "what" was satisfied. At a more detailed level, they used their Enterprise Program Management system for project tracking and dashboard metrics.
  
• They provided leadership training to boost the confidence of their PMs
  
• They moved the project managers from the PMO to the functional areas to encourage collaboration and better align the PMs with the business.
  
• They offered project planning services to assist the distributed project managers with using the new framework effectively (allowing them to use the planning tool of their choice, be it Excel, MS/Word, or a whiteboard). The 25 framework touchpoints, however, are common to all projects for cross-project comparison purposes (I assume enabled in their EPM system).
  
• They redefined "success" as "projects that deliver business value." This gives customer satisfaction and business value even greater priority than being on-time and on-budget (note: they still improved their schedule and budget statistics anyway).
  
  This is the essence of the new model and bears repeating. The customer defines success. Under this model, it's quite possible to have a project that is late and over-budget and seen as a raving sucess.
  
• They tirelessly met with stakeholders in individual and group settings to offer the benefits and ask for their support. They used a subtle soft-sell approach with the "bad actors."
  
• They first involved the PMs receptive to new ideas as part of a pilot and them used them to "spread the gospel"
  
• They measured success rates and publicized them in quarterly reports to senior management.

These are all powerful and valid ways to make a PMO successful. In this case, these changes collectively served to boost IT's credibility at A.G Edwards significantly.

Here's the full article. Don't miss the sidebar "8 Steps for Improving Project Management."

When Failure Is Not an Option - Editorial - CIO

"There is no Spoon" is a popular quote from the "Matrix", where the young prodigy hints to the protagonist while levitating and bending a spoon with his mind, that the spoon is a mere container of energy, and is symbolically irrelevant to reality. Media sponges that we are, we like to cling on to every catchy metaphor we run across, and frame it in our own context.

Software interaction designers have been trying to eliminate the "spoon" for years, to provide direct, unimpeded access to the raw data with which the User will interact, thereby transforming the software itself into an irrelevant, invisible vehicle to facilitate the interactions. Our predecessors, the industrial designers, have forever chased that "perfect fusion" of form and function. For the software interaction designer, the lack of maturity in this field has served as both a challenging puzzle with no concise solution, as well as an exciting time for innovation and pioneering.

I've been involved in the design of eProject's user experience since version 5.0, and with PPM6, we've finally broken through that seemingly impenetrable barrier which has impeded usability improvements for so many other software tools - priority. The information architecture and user experience of PPM6 is the product of time, research, and days on end of trying and re-trying ideas to make that "Spoon disappear". We don't want you to see the software, the user interface, or notice how many mouse-clicks it takes to get to that form. It's all about the data. Seeing and creating the data.

I initially intended this blog to serve as a "behind-the-scenes" view into the thoughts, ideas, and challenges behind the design of PPM6's user experience. However, I think it's only natural to frame this information in a way which may prove useful to you, our users.

1. If we don't know what each User needs, let people who know take care of it.
   

   This sounds like passing the buck, but it's not. You can't please everybody, but we still want to. That's why we've designed PPM6 to give the power of personalization to your Administrator. We've allowed them to control everything from what applications you have access to, to what columns you see in your views. A lot of this power has also been passed on to you. The challenge of this was providing this power without creating absolute chaos and an overwhelming user interface. You'll see a lot of drop-down menu's in PPM6 which behave like your sock drawers at home. What's in them is up to you (and your Administrator). What's important is that you use that power. Pay particular attention to the red drop-down menu that says "More Views...".

2. Don't provide confusing pathways to data. Bring the data to the User.
   

   Websites are great, but websites aren't great tools. It's a clear distinction you have to make. Websites were designed to draw users in, and encourage them to spend time there navigating, absorbing information, exploring. Software tools can't do that. The less time you spend with a software tool, the better. Since we're a web-based software tool, not a tool-based website, we don't want you to explore sitemaps, drill deeper and deeper into our layers of sections and subsections. PPM6 has only three basic areas you need to know. We've taken what was a 16 story building, and flattenedd it to a strip mall for you.

   
   
   
   • The Global Views - these are all the pages you see when you click on a tab at the top. From here, you open and work with items. That's it.
     
     
   • The Project Views - Projects are pages that only provide access to items specific to that project. Otherwise, it works just like the global views. You get to projects from a special tab called "Projects", or by clicking on a project name.
     
     
   • The Item Details - Items are shown as a popup window. Wherever you were to get to that item, you're still there. You don't need to remember how you got there, or where you have to go next. Open the item, read it, or edit the data from the same window, then close it. New items, which are created using forms, open in pop-ups as well. When you're done, save it and the popup goes away, or create another in the same window.
     
     
3. Take Action from a distance.
   

   Items in the list views now have a small blue icon which opens up a dropdown-menu containing most of the commands applicable to that item, whether it be uploading a new document version or editing an issue. Use this functionality just as if you're right-clicking on an item on your desktop. You don't need to open that word document on your desktop to delete it, so why should we force you to open up that item details to update it? Once you get used to interacting with items directly from the list views, you'll find yourself with time to get that extra latte in no time.

   
   
   
4. Take control of your data.
   

   Because of PPM6's new personalization and custom view functionality, you, the user has complete control of how your data can be displayed. This means you can create multiple, well organized views based on context and relevance, or you can create one enormous, horizontally scrolling view in an attempt to cover all bases with one shot. Whichever way you or your Administrator decides, consider environmental factors such as your monitor's horizontal and vertical real estate, your computer's relative processing power, your network speed, and to an extent, your daily user habits. It may take a couple of experimental custom views to organize the data you need perfectly, but a little up-front investment into learning the features of PPM6 and trying out different solutions can pay big dividends down the road in saved time and a pleasant user experience.

The four points above highlight some of the strategic changes to eProject PPM6’s user experience, fueled by lessons learned from 5.0 and collected usability research efforts. As a user experience designer, I feel there is always more to be done, but the few changes noted above make a big impact in the overall usability of the product, which hopefully you will see in due time.

Whether you are creating a project management/delivery methodology based on the PMBOK, Prince2, RUP or other processes or whether you have five phases or nine phases; consider the following as a general guide to what needs to be done in a general order or timing.  I have created many methodologies and use the following as a map to success. 

Initiating Phase

Phase Description

Initiating is the process to define, analyze, prioritize, and approve a project before work can begin.  In some companies, the Initiating phase may not even include the PM or project team unless they are used as subject matter experts by the Governance Committee during analysis. 

 

Each new project begins with the creation of a Business Case, a Project Summary, and the completion of the Project Prioritization Scoring Sheet (let me know if you need to see samples)

 

Once the project is approved, it is assigned a project manager and scheduled against all other active projects using resource and budget constraints.

 

As the project moves to the next phase, a planning team is organized and the project is kicked off.

Success Criteria

• Are the Business Case and Project Prioritization worksheet in alignment with the desired business goals?
• Have all stakeholders been identified and considered?
• Have business and technology risks been identified?
• Has “success” been well defined in the Scope and Project Objectives and do all stakeholders agree on how to measure it?
• Have we considered people and process, technology, and training impacts?
• Has a configuration management approach been defined for all project deliverables?
• Have end user scheduling constraints been considered for the schedule and deployment

Major Activities

(P)        Submit project “idea” in a Project Summary for review

(G)        Create and submit Business Plan

(G)        Complete Prioritization Sheet

(G)        Select or reject project

(G)        Identify Project Sponsor

(G)        Begin Project Charter definition

(P)        Stage project to begin in FY calendar

Deliverables (See Appendix A. – Document Flow)

 (PM)    Project Summary

(G or B) Business Case

(G or B) Prioritization Sheet

(All)      Meeting Reports for all meetings

 

Key:  G=Governance, B=Business Group, P=Project Manager, T=Project Team, A=Business/Functional Analyst, Pr=Process, Te=Test Team, Tr=Training, Q=Quality Assurance/Quality Control, M=Maintenance, (All) Everyone involved

 

Planning and Design Phase

Phase Description

The Planning and Design phase provides the groundwork for the rest of the project and will prepare the project for implementation.

 

The project team is formed and roles and responsibilities are assigned.  The team gathers the detailed requirements providing them with a detailed description of the business capability or technical solution to be implemented.  Requirements will answer the question “what” before the team decides exactly “how” to approach the solution.  Details are identified and documented for the chosen solution and may be business (i.e. process workflows) or technical (i.e. an application, hardware integration, or new network) in nature.

 

The Project Schedule and a number of plans (see deliverables) are created to guide the project team through implementation and testing of the project solution in preparation for deployment according to the gathered requirements.

 

The designs will progress from a high-level (conceptual) to very detailed (physical and logical) and should include functional and operational information.

Success Criteria

• Does every team member and stakeholder clearly understand the expectations and responsibilities of their roles?
• Have we conducted all interviews needed to ensure requirements are comprehensive and clear?
• Have we captured business, technical and operational requirements?
• Have requirements been validated:
  • For completeness?
  • For compatibility with legacy systems, processes, and corporate standards?
  • For regulatory constraints? 
• Are the requirements documented in a standard format?
• Have the requirements been mapped to use cases/stores à test cases à test plans?
• Has the test group created the test plan before the completion of this phase?
• Have we considered future growth and performance?
• Does the project schedule have a baseline and is it published?
• Have business and technology risks been identified and management strategies agreed upon?
• Have we established a process for tracking and managing change requests?
• Has the project budget and tracking process been established?
• Are we able to trace design and test deliverables back to their original source requirements and can we account for all of our requirements in corresponding designs?
• Have we conducted peer reviews to ensure our designs are comprehensive and clear?
• Have all related systems or projects been examined for compatibility or overlap?
• Have we validated the use of architectural standards for data structures, application interfaces, security, infrastructure, business processes, etc.?
• Have we designed in operational features like runtime metrics, audit trails, common error reporting or notification?
• Do designs address maintainability, serviceability, security, recoverability, installation, audit, etc?
• Do designs facilitate the ability to operate in “test mode”?
• Has the training plan and materials been started?
• Has a transition plan been considered for transition to maintenance at the end of the project?  Maintenance should be included during the project planning and implementation to ensure their understanding of the maintenance needs, training, and any other transition issues.
• Have you considered Business Recovery or Business Continuity Planning for your project output?

Major Activities

(P/T)     Review all available project documents from previous phase.

(P/T)     Review any relevant documents from prior, successful projects.

(P)        Meet with Project Sponsor to discuss Roles and Responsibilities.

(P/T)     Meet with Project team to discuss Roles and Responsibilities.

(P)        Complete Project Charter and Project Summary if needed.

(A)        Conduct Requirements interviews and complete requirements documents. 

o         Map requirements to Use Case, Test Cases, and Test Plans to ensure everything has been covered.

(P/T)     Create Project Schedule and baseline before publishing to PM tool.

(P/T)     Complete Project Planning including all documents

(All)      Complete Project Designs.

(P/M)    Start Transition and Deployment Plans

(P/Tr)    Start Training Plan and deliverables

(P/M)    Start Business Recovery/Business Continuity Plan

(P/G)    Conduct Planning and Design Review and gain permission to proceed to Implementing phase.

Deliverables (See Appendix A. – Document Flow)

(P)        Project Charter

(P)        Project Summary

(P)        Request for Proposal (RFP) - optional

(P)        Request for Information (RFI) - optional

(A)        Requirements Documents (Business, Functional, and Operational Specifications)

• Business and System Process documents

(P)        Meeting Reports for all meetings

(P)        Communications Plan

(P)        Risk Assessment/Management Plan (consider the project schedule for risk items)

(P/T) Project Schedule

• Project Budget and Cost Plan
• Project Resource Plan

(P)        Roles & Responsibilities

(P)        Project RAIDCBT Log (Risk, Action Item, Issues, Decisions, Change, Business

            Processes, Training Needed)

(P)        Status Reports

(P)        Change Control Form and Process

(P)        Project Management Plan (Optional, but a best practice)

• Goals
• Objectives/Scope
• Approach
• Assumptions/Constraint
• High-Level Risks
• Timeline/Milestones
• Staffing Plan/Org Chart/Roles and Responsibilities
• Communications Plan/Contact List
• Cost Plan/Budget
• Quality Management Plan
• Change Management Plan
• Issues Management Plan
• Procure Plan

(Te)       Test Plan

(P/All)   Planning and Design Checkpoint Review form

Begin work on:

(Tr)       Training Plan

(P/M)    Transition Plan

(M)       Maintenance Plan and SLAs

(P/M)    Start Business Recovery/Business Continuity Plan

 

Key:  G=Governance, B=Business Group, P=Project Manager, T=Project Team, A=Business/Functional Analyst, Pr=Process, Te=Test Team, Tr=Training, Q=Quality Assurance/Quality Control, M=Maintenance, (All) Everyone involved

Implementing and Testing Phase

Phase Description

During the Implementing phase, we implement what was designed according to the project requirements following the project plans and the project schedule.

 

The Implementing phase concentrates on the creation of new (or revision of existing) processes, application solutions, and/or technology infrastructure components necessary to sustain business capability.

 

Testing really starts during the Planning and Design Phase as the requirements are outlined and move through the progression of Use Cases, Test Cases, and Test Plans to ensure the functionality is included in the finished product.  Testing validates the behavior of the solution and it’s “fitness” for deployment.  Testing should progress from the validation of business or technical requirements through customer acceptance and operational readiness.

Success Criteria

• Have we conducted peer reviews of code and/or processes?
• Have development standards been consistently applied?
• Has unit testing been performed in a structured way?  Are there documented approaches or results?
• Is all source code, process and system documentation under version control? 
• Is there an administrator managing promotion to test?
• Is there a single list of defects to be fixed?
• Has training material been created for users of the system, for operational support, for online help, and/or for the Help desk?
• Have test requirements, cases and procedures been completed and reviewed for readiness?
• Have data naming standards been followed and validated?
• Is there a master list to trace tests back to designs and requirements?
• Is there an agreed upon test coverage goal?
• Have all stakeholders been included in at least one type of testing?  (Including operations, developers, business subject matter experts, business sponsors, technology partners, maintenance and operations team, end users, etc.)
• Have “destructive” tests been designed to stress the system, or have tests only been designed to “prove that the system works”?
• Has a transition plan been created and tested? Does it include “roll-back” options?
• Has the plan for moving the solution into maintenance (Transition) been validated by all stakeholders?
• Has Business Recovery/Business Continuity Plan been finalized?

Major Activities

(P)     Execute project plans and project schedule

(P)     Report status

(P)     Keep project team and stakeholders informed

(All)   Build, Test (Run Test Cases for the following tests: Unit, Systems Integration, User Acceptance, End-to-End, Cycle, Regression, Backup & Recovery, and Stress), and Modify solution as needed

(P)     Implementation planning is completed and approved.

(T)     Implementation tasks are executed

(P)     Conduct Implementing Phase Review and gain permission to deploy solution

(P/M) Finalize Transition Plan

(P/M) Finalize Business Recovery/Business Continuity Plan

Deliverables (See Appendix A. – Document Flow)

(P)     Meeting Reports

(P)     Status Reports<