I was thinking whether to do this in a Blog or a Forum to see which may get the most response, and decided to do it in both. If you feel more comfortable responding to a forum, I have the same post in the PMO Forum. Last night at the Seattle PMO Roundtable, we had a very engaging discussion about the Value of the PMO in today's environment. With the downturn of the economy, many PMOs are being looked at very carefully for their value. I am of the opinion if you were to change a word to the Project/Program Delivery Office, the company would look at this function very differently and have no question to the value provided. If the main focus were one of delivery instead of management and the metrics, personnel, and output of the office were focused on project delivery; your value would be solid. I also believe the failure of some Project Offices is a failure to understand how to communicate up, down, and sideways. A good Project Office will have a Communications Plan to know who, what, when, what format, and how often information need to be managed and delivered. Many PMOs look down, but don't look up or sideways. The Project Delivery Office is providing results for decision making, project initiation, project planning/execution, and project value post-deployment.

 

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

(P)     Updated Project Schedule

(P)     Updated Project Budget

(P)     Updated Resource Utilization Plan

(P)     Updated RAIDCBT Log

(T)     Updated Business Process

(P)     Project/Implementation Metrics

(Te)   Updated Test Plan

(Te)   Pilot and Test Results

(Te)   Updated Test Checklist/Approval

(P)     Completed Deployment/Transition Management Plan

(All)   Solution Documentation

(Tr)    Training Plan

(Tr)    Training Deliverables

(M)    Business Staffing Plan

(M)    Maintenance Plan and SLAs finalized

(P)     Project/Implementation Metrics

(P)     Implementing Checkpoint Review form

(P/M) Updated Transition/Roll-back Plan

(P/M) Final 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

Closing Phase

Phase Description

The Closing Phase provides the opportunity to assess the effectiveness of the project processes, the delivered solution, and formally close the project.

 

Lessons learned and best practices are captured to be used during continuous process improvement sessions and as a reference for future projects and administrative closure takes place to ensure all project accounting is completed. Project resources are formally released after the PM has had a chance to provide feedback to the resource manager for each resource. 

 

Benefits realization and customer satisfaction are handled after the project close by Project Governance.

Success Criteria

• Are measurements for assessing benefit realization understood and techniques in place for tracking them?
• Have sufficient operations or maintenance staff been committed to long-term support requirements?
• Have requirements, defect logs, and other documentation been provided to the support team?
• Are there guidelines for differentiating between routine maintenance and enhancement project work?
• Has the project manager provided performance feedback to the resource manager for all project team members?
• Has all project accounting been completed and all bills paid?

Major Activities

(All)      Complete Post-Project Process Debriefing

(All)      Complete Post-Project Results Review

(P)        Ensure all project billing is complete

(P)        Write up and present project performance feedback for all team members and provide to their resource managers

(All)      Celebrate!

Ongoing by Governance

(G)        Quantify Benefits Realization

(G)        Measure Customer Satisfaction

Deliverables (See Appendix A. – Document Flow)

(P)        Post-Project Process Meeting Report

(P)        Post-Project Review Meeting Report

(P)        Lessons Learned

(P)        Project performance feedback for all team members

(P)        Project Close Checklist/Approval

(G)        Customer Satisfaction Survey

(G)        Benefits Realization (ROI) metrics

 

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

Appendix A. – Document Flow

  

For a larger photo, click here:  PM Documentation Flow

 

In my "Maximizing IT Capacity" webinar the first poll asks "How much of your time do you log? Of the choices, "none" is the most common response, with "project time only" running a distant second. Yet when it comes to understanding resource issues, actual time is the most valuable information around. By analyzing the prior 12 months time records at PeopleSoft IT, we increased our project capacity 30%, and staved off drastic staff cuts during the Oracle battle.

 

Why is this information so valuable? Properly analyzed, it provides insight into 3 key areas.

 

Feedback to project planning

In a PMO, we tend to concern ourselves with resource allocation to projects. We also spend a lot of time estimating task effort and resource requirements. Indeed, these estimates drive our project schedules, and ultimately the delivery dates promised to our customers.

 

So, how do we know if our planning is accurate? Most project managers rely on experience, and hope they're close. But it's the empirical date from time logs that reveals that the 40 hour task that completed on-time actually took 60. People worked overtime, or borrowed someone, to get the job done. And next time, we'll estimate this task as a one-weeker again, but might not get so lucky.

 

Obviously, without tracking time, we are missing the feedback loop to our planning.

 

Analyzing resource constraints

So far, we've discussed time against individual projects. Of course, people often work more than one project, and there's a lot of non-project work to be done as well. This leads to serious resource constraints, with employees and department manages alike complaining about the heavy load.

 

And what's the first line out of an executive's mouth when asked for more resources? "Prove it!" With proper time logs, you can. And you can prove it by department, resource type, skill-set, etc. And you may discover that your networking projects suffer not from a lack of resources in general, but from one skill-set in particular. At one client it turned out they had plenty of programmers, DBA's, etc. What they were lacking were project managers!

 

Time is Money

The largest line item in most departmental budgets is payroll. Therefore, where a department spends it's time is also where it spends it's money. Analyzing time can reveal how much is spent on strategic vs maintenance, projects vs change-orders, etc.  Instead of just looking at which projects fall into the strategic, informational, transactional, or infrastructure portfolios, the entire organization's effort can be viewed this way. Put that in pie-chart report and watch the execs eat it up!

 

One of then biggest obstacles to successful project delivery occurs right at the beginning of the lifecycle – deciding which projects to approve. You take in 20, 50, 100 project requests, and then it’s decision time! What do you do? If you’re like most IT departments, one of two scenarios occurs.

 

1 - The CIO looks the list over and decides, then takes the resulting flack from the stakeholders who were denied. And often his decision is based on the squeaky wheel principle – who will squawk the loudest if they don’t get their pet project?

 

Or 2 - the CIO has had enough of being the fall guy, and either brings the list up to the executive staff meeting or forms a steering committee to make such decisions. This is a huge improvement, in that enterprise level decisions are now owned by the stakeholders. The problem is, most of these discussions degenerate into VP’s arguing over their pet projects.

 

What that steering committee really wants is information. What are the benefits of each project? How much will it cost? What are the risks if we do it? What are the risks if we don’t?

 

This brings up problem #2 – how do you perform a cost/benefits analysis on 100 project requests? That’s a bigger effort than most of the projects themselves!

 

The answer is relatively simple – create scorecards that rank each request on a common scale over a number of attributes. But before we get to that, we need one more item – a good project request form.

 

In most IT departments requests come in haphazardly. The VP of Sales tells the CIO they need a new CRM system. An email comes into the PMO looking for a network upgrade in Boston. There’s simply no uniformity to how requests enter IT, and thus no uniformity to the type of information you get.

 

A good request form provides a method and channel for submitting these requests in a uniform way. While I could write an article simply on creating a request form, for our purposes we are looking for two items:

 

1.        Business benefits. What are the hard and soft benefits expected from this project?

2.        Impact. How many departments, users, processes, and geographies will be affected?

 

Now, on to the scorecard. The idea is to rank each request in 3 areas: Benefits, Costs, and Risks. By ranking each area on a common scale, we can compare apples to apples and make some decisions. A good practice is to break each area into it’s constituent elements, create a 1-5 ranking, then create a composite score for each area using a weighted average. For example:

 

Benefits: Elements could include Revenue Increases, Cost Savings, Strategic Objective, Customer Satsifaction, etc.

 

Costs: Elements should include Incremental Costs, Resource Hours (all staff, not just contractors), On-going Costs.

 

Risk: Elements could include Geographic Impact, Business Units impacted, Number of Systems Affected.

 

The 1-5 scoring depends on the size of the organization. For example, a Fortune1000 company might score incremental costs:

1 = $50-100K

2 = $101 – 500K

3 = $501K – 1M

4 = $1M - $5M

5 = Over $5 million

 

The same idea would apply to each element. Finally, add up the scores in each area and create a weighted average. The end result should be a relative Benefit, Cost, and Risk score for each project request.

 

Who should be deciding the scores? Obviously, the requesting stakeholder has the best grasp on benefits, which is why we asked those questions in the request form. Often, IT has the best feel for costs, and can use similar projects from the past to make a quick call on those scores. And both the stakeholder and IT have information on risk elements.

 

One more quick tip on ranges: Make them broad, so you don’t get bogged down in detailed estimating. At this stage you’re looking to make some quick cuts to get your request bucket down to a reasonable level. The remaining projects can go through a more detailed analysis for final decisions.

 

If you put all those scores into an eProject Dynamic App, you can then plot them onto a classic quadrant grid using Crystal (as I've done in the PMO in a Box solution set). Anything in the high-cost, low-benefit quadrant can be tossed. The low-cost, high-benefit projects are a no-brainer – get them going! The low-cost, low-benefit projects are small and can often be squeezed in for some quick wins. You’ll have to really think about the high-high projects – but that’s what steering committees are for!

STEP 1 (1-3 months)

• Meet with Governance or the Project Steering Committee to craft a PMO Director or PMO Manager job description
• Hire the right people

STEP 2 (3-5 days)

• Hold PMO Planning session to discuss PMO Roles, assign committee chairs, discuss deliverables, and timeframes

STEP 3 (10 weeks)

Project Inventory Focus (or Committee):

• Initiate a review of current projects by segmentation:  by Division, by Project Management Office, by Initiative, by department or division, etc. 
• In this age of electronic communications, establishing a physical project office will not move your company ahead.  You need to establish a collaborative workspace, a Virtual PMO to allow your management, stakeholders, project team members, and clients to stay informed and connected with project information in real time. 

Gather:

• Project Number (if present)
• Project Name
• Project Description
• Business Initiative Alignment
• Internal or External
• Division
• Department
• Project Type (Application Development, Infrastructure, etc.)
• Project Manager
• Project Sponsor
• Requestor and Internal Priority
• Start Date
• Estimated End Date
• Actual End Date
• Percent Complete to date
• Estimated Budget (Planned Value or Cost Forecast)
• Actual Cost (AC) to date (may be estimated)
• Estimated Risk (H, M, L)
• Customer Impact/Benefit
• Investment Type (Expense, Capital, etc.)

Calculate:

• Estimated ROI or Revenue
• Schedule Variance
• Cost Variance

If possible, use Collaborative Workspace or Project Portfolio Management (PPM) Tool (such as eProject) to Present:

• Project Health or Status
• Portfolio Alignment (by Initiative, Goal, LOB, Department, Division, etc.)
• Project Variances (Costs, Resources, Scope, Change, Schedule, etc.)

Project Development/Training Focus (or Committee):

• Define Roles and Responsibilities (Project Review Boards, Project Governance Committee, Project Office Personnel, Project Managers, Project Coordinators)
• Create Job Descriptions
• Create Career Paths
• Designate individuals per identified roles
• Create Project Management Methodology, Templates, and Toolkits by project phases

Project Tools Focus (or Committee):

Create Tools Requirements for

• Project Management Tool
• Project Portfolio Management Tool
• Project Portfolio Scorecard
• Evaluate tools and make recommendations for solutions. 

HARD RULE: Tools MUST work together and training MUST be a part of solution.

 

STEP 3 (6 Weeks)

Project Inventory and Governance Focus (or Committees):

• Make recommendations for retaining, consolidating, shifting project resources, or killing projects based on metrics, duplications, alignment with corporate initiatives, revenue, and project resource availability.

Project Development/Training Focus (or Committee):

• Create training plan with outlined courses and course progression toward company project management training and certification if desired
• Ensure every project manager has Development Plan in place for including company project management certification training
• Create company project management certification training tracking system to track and communicate training progression
• Develop feedback system to assess training effectiveness

STEP 4 – IMPLEMENTATION (3 months)

Development / Training

• Initiate company project management certification training
• Initiate PM Tool(s) training
• Bi-Weekly Report on training progress and student feedback
• Communicate PM Career path and post any open positions.

Tools

• Execute PM Tool(s) installation
• Communicate installation progress and tools strategy

PMO

• Track active projects for PPM updates
• Offer coaching and mentoring for PMOs and projects without PMO coverage
• Offer PM Consulting with available resources

I feel many of the foundations of project management are taught without urgency and as if things were frozen in time.  We actually work in a very dynamic environment.

Though I have been teaching project management for years, I have changed my focus to one of teaching project delivery instead of just project management in the past few years.  Knowing how to deliver a project is much more valuable in today's environment than just knowing how to manage a project.  The Project Delivery Expert (PDE) needs to have the skills, acumen, and confidence to actually deliver a project with the constraints of a tight scope, a finite budget, a tight timeframe, with limited resources from a matrixed organization, with a focus on quality, trying to keep everyone informed at all times with information they feel pertinent, and having to delivery within the confines of a siloed organization.  Though that doesn’t fit all environments, it is the combination of the environments I have seen over 27 years in project management.  The focus on project management lacks the urgency of inertia and "getting it done!"  If we changed the title from PM to PDE, I think people would be more accountable and we would see a lot more results.  I would also pay PDEs for what they deliver within the constraints above.   

I have worked to provide many solutions in the areas of PMO, PPM, Governance, project/program management, and project management tools.  Most are focused on looking back to see how you have done or looking at today, hoping you know where you are.  I think we need to change our focus to be more of looking ahead.  I want to know what you have done, of course, to be sure we are managing to expectations; but I also want to plan ahead to avoid issues and risks.  I want to plan a project as a military exercise and plan out all areas of uncertainty and train to deliver by actually providing exercises to expose areas for skill development and the ability to act as an autonomous team to accomplish what needs to be done without having to go to a senior team for guidance or coaching on every aspect of the project. 

I believe if companies actually want project delivery, they need to invest in delivery skills for their teams.  The PDE needs to be given skills and the authority to lead team through challenges and deliver to scope.  The project teams should be trained as a team and develop the confidence in their team members to deliver what is called for.  If a team is trained as a team and is given challenges to solution as a team, they will succeed in ways many countries and companies haven’t ever seen.   

We can combine the energy and enthusiasm going into Lean and CPI efforts to deliver projects.  The teams will plan, design, and deliver as teams and continue to develop their skills and experiences as they deliver projects.  I have seen many teams created, only to be torn apart as they reach their highest potential for delivery as a project completes. 

In many projects, I have seen this enthusiasm and confidence only from consultants and contractors because they have had the fortune to have the right training or exposure to situations to learn necessary skills.  Many internal project teams lack the same confidence because they don’t have trusted leaders, don’t know the skills of their team mates, or haven’t been exposed to an environment allowing them to actually provide project delivery instead of just project management.  They need to try new approaches as a team and stay together to learn and grow from experience.   

I really believe companies will be able to finally achieve “more with less” in this environment because people will be at the highest level of Maslow’s hierarchy and not working at the lowest levels as I have seen in many project management teams.  They will actually become project delivery teams and they will be led by a Project Delivery Expert.  Some teams may be able to grow to the state of self-actualization and be able to rotate team members into the PDE position for different projects.

Comments?

The Ten Faces of Innovation, by Tom Kelly of IDEO, with Jonathan Littman, is an excellent book on how to create a truly innovative environment (as opposed to just saying "from now on, we're going to be innovative"---which nearly never works).

Some think that innovation has nothing to do with project management---that innovation is about generating ideas, and project management is merely about executing them. In my view, this is absolutely wrong, as you will hopefully see as I share a summary of Tom Kelley's book.

All in all, there are three groups of "personas" Kelley covers in the book; The Learning Personas, The Organizing Personas, and the Building Personas. The premise is that by adopting these personas, we can achieve true innovation.

As noted in the book, it's important to note that each persona is just that, and not a "position". Some people can have multiple roles, and not all roles are needed on every project. But in general, the more roles that are covered, the more successful your venture will be.

Here are the personas, adapted from the book, with my own comments added (keep in mind that the book offers a heap of antectodal information that supports these personas---real stories from real companies).

The Learning Personas

1) The Anthropologist – Observes human behavior and empathizes in order to determine what’s really needed. Fanatically keeps lists of issues and ideas. [As Toyota's slogan goes, “Go and see for yourself.” Don’t judge by a needs survey alone.] Henry Ford said, “If I had asked my customers what they wanted, they’d have said a faster horse.”

2) The Experimenter – Likes to try new avenues, using fast, inexpensive prototypes. Not afraid to think out of the box and “fail often to succeed sooner.” Uses enlightened trial and error. Can also do "implementation by experimentation" for multi-locations by engaging remote sites in prototyping, and letting them adapt to their site as needed (as opposed to a rigid “rollout”).

3) The Cross Pollinator – Examines other industries, genres, and cultures, to mine for ideas and look for analogies. These are typically “T-shaped” people, with a deep understanding of at least one core area and a broad interest in many other topics. Well-rounded, and with many interests, these people are a core source of ideas.

The Organizing Personas

4) The Hurdler – Bends the rules to get around roadblocks. Hurdlers tend to be street smart and can cleverly work around the system, undeterred by adversity. Seemingly stubborn at times, they listen to experts, but don’t let them have the final word.

5) The Collaborator – Brings diverse groups together, even if leading from the middle of the pack. Wins over skeptics and creates solutions that cross boundaries. Breaks through silos by being the glue that holds the diverse group together. Works “with” the client instead of “at” them. Prefers to coach rather than direct, coaching behind the scenes and letting the team run with the ball and have the glory. Doesn’t second-guess people from the sidelines.

6) The Director – Assembles the right people and gives them an environment that will allow their creativity to flourish. Has good strategic vision and sets the right theme. There’s no one style that works best. Some lead with calmness and others are bundles of energy. But they all give center stage to others, love sparking new ideas and projects, aim high, and embrace the unexpected with a variety of techniques, strategies, and resources. This role can be on a specific team and does not necessarily have to have a position of “director” authority in the corporation.

The Building Personas

7) The Experience Architect – Designs the customer experience, beyond just the functionality of a product. Comes up with new and creative ways to awe the customer, yet with the same basic product functionality. An example is Cold Stone Creamery, which creates an entertaining experience where the server mixes ice cream with any number of desired toppings on a slab of cold stone. The servers even put on shows. [my added comment is that The Experience Architect can learn from observing others, even in other genres, and as such can gain from the “Cross-Pollinator” and “Anthropologist” personas.]

8) The Set Designer – Creates a fun and vibrant physical working environment that can spark creativity and collaboration. Allows employees great latitude in their personal work spaces. Avoids dull, repetitive spaces. Creates formal and informal public spaces where people can collaborate and brainstorm, with all the appropriate supplies and accommodations.

9) The Caregiver – Anticipates customer needs before, during, and after the engagement, and goes above and beyond normal expectations. Makes it easy for the customer to select the right services, provides useful and quick information when needed, insures easy accessibility by the customer, and builds lasting relationships with the customer.

10) The Storyteller – Builds internal morale and external awareness through compelling stories and case studies that reinforce key values or traits. Builds “corporate legends” that get passed around. Not “spin doctors,” the storytellers get their stories from first-hand accounts from customers or employees. Storytelling builds credibility, unleashes people’s emotions, helps teams bond, and generates lessons learned.

Well, that concludes my summary of Tom Kelley's The Ten Faces of Innovation, and its applicability to project management. As you can hopefully see, what project manager wouldn't benefit from these learning, organizing, and building personas that can lead to a better customer experience, a more satisfied team, and a memorable result?

Sure, we can (and should) still define the scope of the project, manage changes to the agreed-upon scope, and use project scheduling and budgeting techniques (we don't want to throw the baby out with the bathwater). But we can take our projects to the next level with a strong dose of innovation, and these personas are as good a way to do that as any.

I highly recommend the book to any project manager or leader who wants to take their projects to the next level.