These are usually quantitative and provide guidance on correctly prioritizing risks (and therefore allocating the planned contingency budgets). One other term that I usually recommend when talking about Risk is “Risk Clarity Date” – a term I use to describe the possible date when more information about the risk becomes known to re-evaluate it.

Typically, projects look at the Risk log every x weeks to go through all the risks and figure out if something needs to be changed – this is not very realistic, since many risks are either time-based or event-based.

For example, if there is a Risk that a software component being developed will not be on time, but this is not going to change unless more information on the actual progress is available.

How do you do risk management? At Project levels only or do you have a Enterprise-wide Risk Management process? Share with us.

Get the PDF version in your email

Related posts:

1. PMO Series: Change Management
2. Series: Project, Program and Enterprise PMO
3. PMO Series: How to Review Projects

If it has a short memory, mistakes happen repeatedly, while a long memory causes fear of failure by thinking “Oh, we have tried it”

Get the PDF version in your email

No related posts.

The second part looked at the role of PMO in setting up and monitoring Change Management processes and activities.

The third part discussed the Quality Management responsibilities of a PMO and provided a table of contents to a Quality Management Plan

This post shares some information and experience on how the PMO can review projects and what to focus on in such reviews.

One of the most important functions of the PMO is to periodically review projects, to be able to answer the  following questions:

1. Where is the project wrt where it should be?
2. Will the project deliver on its objectives – timelines, quality etc?

We have all worked on projects, where the status is green for weeks and even months and suddenly moves to  “Red” one fine day.

The best early warning system is effective and in-depth reviews by the PMO for each project in its portfolio. The frequency of such reviews depends on:

Size of the project

If the project is large and complex, one review meeting with all stakeholders is not effective. There is usually too much discussion on some items, especially those that are over the tolerance levels, while routine ones are not given much time. Instead, multiple reviews with separate teams will provide the necessary focus and insight into that area.

Separate reviews also help you to validate information being provided by one team with others. with a single meeting, contradictory statements are not voiced due to fear or a desire to avoid conflict.

If the project is small or medium sized (<30 – 40 people and less number of cross-domain teams), a single review can be effective as all stakeholders can present information quickly.

A typical review should not be more than 3 hours, as information overload sets in and people become mentally tired.

Criticality to business

Review depth also depends on how important the project is to the business. For example, a public-facing market solution will need to be monitored much closely than a project for generating MIS reports.

Current status

• If the project is progressing smoothly, with interediate deliverables on time and within quality limits, you may want to schedule a monthly meeting with offline status reports weekly.
• If the project is just about surviving, weekly reviews are necessary to tightly control the ship.
• Iif the project is behind on timelines or there are escalations from customers (can be internal such as marketing, end-users etc), day-wise monitoring may be required.

This does not mean having long meetings everyday, but you may request for daily status reports to be circulated to the governance team, with meetings held twice in the week.

What should you review

At the minimum, the review should focus on

• Verify status of tasks with respect to the Plan
• Reviewing Key accomplishments during the reporting period
• Understanding key deliverables and activities during the next period and the progress on them till now to determine if they will still be met. A good way to do this would be to ask for Estimated time to complete in-progress activities and verify against the plan
• Check for Dependencies for the upcoming activities to see if there are any impacts due to external and internal dependencies (such as staff from another team, software or hardware availability etc)
• Status of top issues and any new issues added
• Status of top risks and any updates to the Risk profile
• Change requests created/modified during the period
• Quality indicators such as defect trends, incident escalations etc

How to review effectively

• Instead of having a template which can restrict information, ask the project to develop something incorporating the above. The main point of this is to ensure they don’t feel constrained to report in a manner they feel uncomfortable with
• The report can be simple to start with, but must be able to provide enough information for the PMO to decide on the true status of the project.
• Status is usually shown in Traffic-light symbols, but this generally is not accurate or atleast consistent. Insist on objective criteria to determine what is yellow and what is red.
• Watch for tasks that rapidly change in progress completion, especially ones that slide downwards.
• When people use vague qualifiers like “I think it should be done in a couple of days” or “I believe we are on track”, look at start and end dates of the activity to gain an idea of the effort consumed. Ask for time to complete to gain a true understanding of the remaining work
• A major factor in missed deadlines is underestimating the time it takes to solve operational issues. A solid issue management mechanism will help PMO understand the blocking issues that could impact the delivery
• How is product doing with respect to Quality? Are defects being captured accurately? Schedule and review external audits that verify this one process specifically, since defects may not always be reported under the belief that they are minor
• Take the time to review customer feedback, if any and see how it dovetails into the performance of the project
• Periodically reviewing risks is one of the most important tasks of the PMO. Risk profile must be kept updated when more information is received on a subject that is impacted by a risk

Important Note:

The critical part, I cannot overemphasize this, is that the project must feel that the PMO will do anything to help the project solve issues and move forward. This may mean releasing additional funds or add experts for short durations to solve problems. If the project team feels that the PMO is only reviewing/policing, it will find ways to hide information.

You can find an example of a status report template (and some other good ones) at Derek Huether’s blog Critical Path.

Conclusion

A project review is a good opportunity for the PMO to demonstrate leadership to the projects. Transparent communication, accountability, decision-making and support are necessary elements to conduct a good project review.

What’s your take? What have I missed completely? Do you have something more to add?

Get the PDF version in your email

Related posts:

1. PMO Series: Quality Management
2. Series: Project, Program and Enterprise PMO
3. PMO Series: Change Management

The second part looked at the role of PMO in setting up and monitoring Change Management processes and activities.

This post looks at the Quality Management/Assurance responsibilities of the PMO.

Quality Management is a less-emphasized function of the PMO. In large IT organizations, primary Quality guidance is provided by a centralized Quality function and actual implementation guidance by the PMO. For smaller IT organizations, the PMO.

However, it is important that the PMO incorporate the Quality Management aspects into its guidance and governance systems, since process-orientation can bring in discipline and streamline all activities in the Programs/projects.

The key responsibilities of a PMO for Quality Management include:

Setting up quality standards if none exists or tailoring organizational standards
Provide guidance on defining acceptance criteria to measure successful completion of the project
Provide guidance on setting up Program and project specific metrics for monitoring, tracking progress and quality
Schedule, conduct and review Program and project audits to ensure they are following the guidance provided by the PMO.
These aspects can be detailed out in a Quality Management Plan. A well-structured QM Plan can help the Program/Project adhere to the accepted practices in their projects. In addition, the PMO may also provide
Quality management support to projects through a dedicated team of people.

A typical QM Plan will have the following Table of contents (sections):

• Reference to organizational processes (if available)
• List and reference to any adaptations to the organizational processes, templates and checklists
• List and reference to program/project specific processes, templates and checklists
• List and reference to all standards/guidelines (including technical, industry-specific regulations, domain etc)
• Release Reviews performed by the Quality function before any customer/production release
• Program/Project specific metrics and tolerances
• Work product reviews that will be performed by people in the Quality function
• Tools and techniques used for Quality activities
• Defect prevention, causal analysis activities and techniques
• Reports and Dashboards
• Frequency and timing of project reviews and audits by the Quality function

If you have implemented the Quality Management function as part of the PMO, we would love to hear your experiences and challenges.

Get the PDF version in your email

Related posts:

1. PMO Series: How to Review Projects
2. Series: Project, Program and Enterprise PMO
3. PMO Series: Change Management

We started off the PMO series with a basic introduction about the PMO – terminologies, the different types of PMO and some of its typical functions.

Let’s talk about one very important part of a PMO function – Change Management. Change is the only constant in life – cliched? Of course, but true nevertheless. It is also one of the biggest causes of “project death” – those projects which go on indefinitely, but always overdue and a cost sink (read an extreme example of how change in scope resulted in a 12-year project that was also a massive failure!).

In a large project/program, change management becomes very important to ensure that something remains stable or atleast manageable.

Change Management has become the norm in the industry today and there are dedicated “Change Managers” too sometimes, but there is enough change mismanagement too. One of the biggest reasons for this mismanagement is because it is used synonymously with managing Requirements Change.

Managing change does not only mean managing changes to scope (“scope creep”, as it is called, but that is a creepy term). Architecture/Design decisions, standards and tools also must be controlled to prevent chaos. This is where most change management processes fail.

Let us look at some change management mechanisms and then we will revisit how change management can be applied.

Change Control Board (CCB):

One of the most common responses/techniques, but often under utilized. The CCB need not be a single, all-powerful entity, but there can be more distributed ones at different levels. For example, for large architectural changes, there can be a high-level CCB, but smaller design decisions can be changed by a lower level CCB. It is usually good to organize such mini-CCBs by the amount of control they have rather than by phase – this will create cross-functional teams at all levels, rather than more silos by function

Change Request Creation and Tracking processes:

Having a formal Change processes itself is a barrier to most spur-of-the-moment change decisions. At the minimum, change request processes should describe how a change request is created, who reviews it, criteria for escalation, stakeholders to be involved and change closure. It also needs to tie in Configuration Control for effectiveness.

Incorporating change (and its consequences) into planning:

Usually this is a fatality in most change processes. Changes to non-scope areas of the project are considered to be immune to schedule or cost effects, which is rather unlikely. Sometimes, the development team is asked to absorb the effect as the price for not understanding or doing it right the first time. Managers in charge of change control must resist this thought process or risk losing much more at a later stage in the project.

Stricter controls as Project progresses

At the start, change is more likely, since everyone is feeling around in the dark, establishing sign-posts and installing lights, figuratively, but as you progress in the project, it is important to ensure that every change request is asked “why” several times. Any change later in the lifecycle, especially with respect to decisions, is likely to affect work products already produced and accepted. A common victim of this syndrome in an application development project is the User Interface, which is thought to be like a skin – easily replaced, but is it? In services, Change is more tightly connect to configuration than with Application development, but the principle still holds true.

Having looked at some mechanisms for managing change, let us go back on how and where to apply change management. Change Management in an application development scenario can be used at:

• Scope management
• Technology stacks
• Architecture
• Design
• Standards to be followed, such as branding, user interface etc
• Third-party components
• Development environments

In a services environment, change needs to be managed for

• Hardware
• System Software (OS, standard application software etc)
• Communication equipment
• Services and their endpoints
• Processes and
• knowledge databases

Note: In IT Service Management circles, the CCB is termed as CAB, shortened for Change Advisory Board (though why it just “advises” stumps me).

That’s alright, I know this stuff, but where does the PMO fit in, you ask? PMO must be the oversight for managing change. The PMO establishes the procedures for change control and provides necessary direction to the Program on the levels of CCB (scope of change control, escalation criteria etc). It is also the final arbiter for changes to Project scope, schedule or cost.

In fact, for rescuing troubled projects, one of the first things a PMO should do is to take a hard look at the project for change leaks and based on the amount of leakage, institute an appropriate level of change control. I say “take a hard look” since it is almost guaranteed that a typical derailed project has issues managing change.

What are you experiences in managing change in your projects or services? Is there something else? Think and let me know about it.

Get the PDF version in your email

Related posts:

1. Series: Project, Program and Enterprise PMO
2. PMO Series: How to Review Projects
3. PMO Series: Quality Management

Collaboration is a dance of contribution, requiring that people alternately step forward to contribute and step back to let others contribute.

Old, on the Internet timeline, but timeless on the timeline of human endeavours.

I cannot possibly write anything on this that is better than what Alistair has already said. Maybe, some experiences/observations, but that is for a later date, when I have really understood in depth his thoughts. Read the complete post “Collaboration is the dance of contribution“

Get the PDF version in your email

No related posts.

Project Management began to be studied as a separate discipline and project management activities and skills were codified as Frameworks. Some well-known Project Management frameworks currently in use are the Project Management Institute’s PM Body of Knowledge (PMBOK) and PRINCE2.

With IT receiving more attention (much negative too), standards, planning and tracking became important to organizations. Setting up standard project management practices, oversight of plans, tracking and reporting became a priority. Thus was born the Project Management Office (PMO).

Programs got their own Program Management Office and now there is the EPMO – the Enterprise Program Management Office, a corporate level PMO that sets standards for Programs across the organization.

The role of a PMO has grown so important that it is listed as one of the roles in the RACI matrix in COBIT 4.1, the commonly used framework for IT Governance.

But the basic activities/responsibilities of the PMO remain consistent in principle, if not in scale. Some of the typical PMO activities include:

• Program and Project Planning
• Tracking
• Risk Management
• Financial Management and Reporting
• Change Management
• Staffing andTraining
• Quality Management

Based on the organization, the functions of a PMO may include other activities not listed above.  It is becoming increasingly clear that using a PMO can improve the project delivery performance, provided we know where and how to use it.

In an entry at CIO.com, Jim Vaughan discusses this issue in “Developing Your Project Management Office (PMO)”

We will look at some of the activities of the PMO in more detail in the next few posts. If you have some links of blogs, articles or whitepapers that document any of these aspects or you have some links to some templates, please share them with the community. You will receive an attribution with your name and website.

Before you leave, here is a good link for you. Download TenStep’s white paper (pdf) on building a PMO

Merry Christmas

Get the PDF version in your email

Related posts:

1. PMO Series: Quality Management
2. PMO Series: Change Management
3. PMO Series: How to Review Projects

CIO.com has a great series on what Cloud Computing means for the CIO (and IT departments) and surprisingly, makes a case against it; but only because it is not ready for large-scale deployment.

Currently, barriers against adoption of cloud computing are in the realms of technology accessibility and security. While the first can be worked out over time, security remains an essential element that needs to be balanced.

However, considering that cloud computing offers IT the opportunity to reduce costs through hardware and application consolidation, improved outsourcing capabilities, rapid deployment of new technologies, security may just become a footnote.

While public cloud computing services from Google, Microsoft (yes!), Amazon and other will continue to increase, these will primarily attract customers from the small and medium business segments, where IT is not a competitive advantage. Very large organizations may opt for private or hybrid clouds, simply out of fear of data integrity and privacy concerns. also, custom application development is not possible in the cloud computing scenario.

One scenario that remains to be played out is the use of proprietary software or open source software to drive the cloud. I suspect that over the long run, businesses may not care what is used, as long as it meets requirements consistently. For example, office software, email, instant messaging etc may be open source, while special software such as company applications will continue to remain proprietary. There may be other solutions that are available in the cloud, like salesforce.com, but the lack of customization options can be a deterrent to some.

In the end, the level of control available to the organization in using its data will determine if cloud computing is here to stay. If the cloud provider vanishes tomorrow, can I get the only copy of my data? If the cloud provider hosts my data in a country where privacy laws are biased towards the government, will there be any issues?

Technology has never been a barrier to adoption. Control and trust are the keywords which will decide if cloud computing is here to stay.

Get the PDF version in your email

No related posts.

Compared to the earlier report, the number of projects that are successful has gone down (to 32%), while the number of cancelled projects has gone up. From my perspective, this is a good thing and a bad thing.

The bad thing being the drop in success rates, while the good things is that there seems to be increased monitoring of projects and cancelling them when it becomes clear that they will not deliver expected value.

However, respected researchers like Robert Glass(www.robertlglass.com) have questioned the research methodology and criteria used to collect and analyze the data.

I think that due to such questions, the Standish Group has quietly removed the Summary report (costing $99) and replaced it with a “CHAOS Manifesto” (costs $1000) that (hopefully!) provides in-depth information on the results of the research and the research methodology itself.

Get the PDF version in your email

No related posts.

Please subscribe using your favorite RSS reader to get updates when there is a new post.

Get the PDF version in your email

No related posts.