Skip to main content

Tag: Stakeholder

From the Sponsor’s Desk – Projects Done Well, a Recap – Part 2

Written by Drew Davison on . Posted in Articles. 15 Comments on From the Sponsor’s Desk – Projects Done Well, a Recap – Part 2

In my last post, Projects Done Well, a Recap – Part 1, we started to look at the lessons learned from the 22 case studies we’ve covered in this blog over the last two years. We covered three of the top nine contributors to project outcomes, all effecting more than half the cases studied.

In this post, we’ll look at the final six factors that most contributed to project success or failure and suggest how you can leverage these findings to improve the performance of your own projects.  

The Methodology

DrewSept26th3

Check the Part 1 post if you’d like a refresh on the methodology we used. Essentially, we analyzed the 22 cases presented in the From the Stakeholder’s Desk blog on Project Times against the 18 Factors in Project Pre-Check’s Decision Framework. The Decision Framework helps stakeholders form and deliver a common vision for a planned change from inception through completion. In Part 1, we looked at two factors in the Change domain – Stakeholders and Dimensions, and one factor in the Environment domain – Business Plan. In this post, we’ll look at three factors in the Assets domain – Resources, Delivery and Project Management and three factors in the Project domain – Planning, Control and Communication. This should shed still more light on what we can do to make projects routinely successful.

The Findings

In summary, nine of the eighteen factors in the Decision Framework were identified as critical to the project outcomes in ten or more of the cases as shown in the chart. The bottom line: get your stakeholders agreeing on these factors first and your project has a much better chance of achieving its goals.

The nine factors identified here as the leading contributors have a broad impact on pretty well all business and technology projects. Pay special attention to them.

The Assets Domain

The Assets domain addresses stakeholder decisions regarding the people, processes, products, tools and facilities that are required to support a planned project or which may need changes for the project to succeed. In essence, the Assets Domain is the supply cabinet to the project world.

DrewSept26th2

Resources

The Assets domain includes the following factors: resources, delivery, project management, business operations, security administration, technology operations and infrastructure. Three of those factors contributed to project success in our review: resources, delivery and project management.

The Resources factor includes seven decision areas including skills and capacity, skill development, resource procurement, contract management, team formation, performance management and succession planning.

The Resource factor was a contributor to project outcomes on 19 cases.

In The Offshoring Challenge, Part 1, the challenges of forming effective teams and ensuring the availability of required skills and capacities with an off shore software development organization were never tackled. The domestic and off shore teams never really had shared goals, objectives, processes and ground rules, there were no actions taken to address the cultural and language differences and the distance and time zone challenges were never dealt with. The final result: actual costs were double the original budget and the project was delivered nine months late.

Why is the performance management decision area a concern to stakeholders? Check out You Get What You Pay For. In that case, the two project managers were incented to meet a date. So they met the date! Unfortunately the implementation was a disaster. Nothing worked. The changes were pulled out. There was no contingency plan so the reversion to the original systems was messy and time consuming. The cost to complete the project ballooned to $70 million, 40% greater than originally forecast.

In the post Tenacity Can Achieve Miracles, the QA manager had the knowledge and skills necessary to turn around a serious quality gap that was causing a loss of customers and revenues. She was also able to tap into an available supply of QA talent to lead her teams successfully. In addition she was able to form three multi-disciplinary teams quickly and effectively using her knowledge of team building practices. She brought together small groups of staff with clear mandates, appropriate availability, the right perspectives, knowledge and skills and short term time frames to deliver a meaningful result.

Finally, Fix the Business Process First demonstrated the kind of success that can be realized when the right skills and capacity are put in place. In this case, the organization had never done an end-to-end process assessment. The sponsor contracted with an external group that had proven capabilities to assess end-to-end process performance to manage the project. That included a “boot camp” for involved executives and staff to reorient their frame of reference from organizational silos to a process view. The project was a resounding success.

Takeaway: the stakeholder group needs to have a complete understanding of the Resource factor decision areas relative to the project needs and be fully on side with that view and any plans to address the gaps.

Delivery

The Delivery factor addresses the processes that are in place and can be used or adapted to develop and implement the target solutions. The Delivery factor includes the following decision areas: management of change, software delivery, technology change, quality assurance, prototyping, partitioning, time boxing, reuse and project close.

The Delivery factor had a material impact in 11 of the 22 cases.

An example of a project that paid the price for not addressing the Delivery factor was presented in the post Managing IT Services Contractors. The project was delivered successfully, but five months late and sixty percent over the original estimate. The vast majority of the overrun came from the contractors’ failure to deliver. Key contributors to that failure were the lack of technology change and QA processes that the participants could use as a road map for managing the change. That contributed to numerous disconnects between the project team and the contractors on key fundamentals including roles and responsibilities and the quality practices and a plan to deliver to those expectations.

In Knowing Your Project Profile, the project ultimately delivered a significantly better return than originally anticipated but the two project managers ended up as goats. They adapted the in house quality practices ensuring a high quality solution in all respects. They used prototyping effectively to understand the business requirements. Unfortunately, they didn’t address the incremental functionality that was added to the scope resulting in higher costs and more time. That surprised the other stakeholders. They also missed an opportunity to partition the project into phases to accelerate benefit delivery and reduce risks. If the PM’s had considered the Delivery factor decision areas up front, they might have been heroes.

Takeaway: it’s imperative that the stakeholders have a discussion on the processes and practices that will be used to deliver the solution and are in agreement on the decisions reached. This factor is often seen as the exclusive responsibility of the PM but keeping it to oneself is a mistake. The more the other stakeholders understand the choices and agree on the direction chosen, the greater the overall commitment.

Project Management

The Project Management factor covers those practices and guidelines that PM’s can use off the shelf or amend as appropriate to guide their projects. The Project Management factor includes the following decision areas: the project management process, organization profiles, estimating guidance, project tracking and reporting templates, requirements management frameworks and standard practices on risk management, issue management, change control, defect tracking and gating.

The Project Management factor was a material contributor to the success of 11 of the 21 cases.

In the post Anybody Can Manage a Project, Part 2, we saw how a new hire with a financial background and no prior project management experience was able to deliver a global project successfully with accolades from all the stakeholders involved. Part of her success was due to the use of in place processes and templates to guide her actions, including the standard reporting templates which she tweaked to address her sponsor’s needs. She also obtained stakeholder agreement on the risk management, issue and change control practices to be used on the project.

In the post Anybody Can Manage a Project, Part 1, the individual assigned to manage the project had no prior project management experience either. However, in her case, she didn’t have the benefit of stakeholder discussions regarding the project management process to use, how to estimate the work, manage requirements, track and report progress, manage risks, issues, changes, etc., nor did she take advantage of materials or expertise within the organization that could have helped. A new project manager was finally assigned and the project was delivered for almost twice the original budget, nine months late.

Takeaway: all stakeholders need to be engaged in a project on a regular basis, certainly weekly, often daily. They need to know how the work will be planned and managed, who the players are and what their responsibilities are, how they’ll be involved and the basis of that involvement. This factor is also often seen as the exclusive concern of the PM but that’s unwise. Stakeholders who understand the choices and agree on the direction chosen will be more committed and more effective.

The Project Domain

The Project domain addresses the specific project decisions that need to be made to shape and deliver changes that achieve the organizations goals. These decisions deal with how to deliver to the stakeholder expectations articulated through the decisions made in the other domains. The Project domain includes four factors: planning, organization, control and communication. Three of the factors – planning, control and communication – were among the top nine factors contributing to project success.

Planning

The Planning factor takes the relevant decision areas addressed in the Assets domain and applies them to the unique needs of the project. Huh??? OK, an example: if the stakeholders agree that they don’t have the right skills, or enough of the skills required when considering the Resources factor in the Assets domain, then the plans to address that gap are included under the Planning factor. It covers the following decision areas: business alternatives, technology alternatives, release plans, cost estimates, benefit plan, quality plan, resources and facilities plan, contracts plan, communication plan and risk plan.

The Planning factor was a contributor to project success in 13 of the 22 cases.

The Power of Teams post shows the positive results that can be achieved by building a resource plan that addresses the critical skill and capacity needs. As well, the project developed and managed a comprehensive risk plan that was used to guide the project around and over the many obstacles that arose. The project implemented successfully just prior to the yearend freeze, twelve and a half months after launch. The actual cost was slightly under budget and the quality of the delivered software, processes and services was outstanding.

On the downside, The Offshoring Challenge, Part 1 shows what happens when the Planning factor decision areas are ignored. Identification of possible risks and development of a mitigation plan is a prerequisite for just about every successful major change undertaking. Had that been done in this case, chances are the risks relating to quality, communication, team performance and expertise and other factors would have been addressed. In addition, there were no plans to manage the vendor contract, the quality of the delivered products, skills and capacity issues and guide the communication with the stakeholders. The final result: actual costs were double the original $7 million budget and the project was delivered months late.

Takeaway: exposing the Planning factor decision areas to the other stakeholders and asking them for their thoughts on each item can be intimidating. Early on, the majority of response will be, more often than not, “I don’t know”. However, as the project progresses and positions and proposals are developed, the dialogue will increase and stakeholder collaboration will evolve to mutual understanding and, finally, agreement. How powerful is that! Take advantage of it – a process to gain stakeholder agreement and cement their engagement at the same time.  

Control

The Control factor includes those control mechanisms that help stakeholders shape and guide the project to achieve the objectives of the planned change. It includes the following decision areas: release plan performance, contracts plan performance, risk plan performance, team plan performance, change tracking and reporting, issue tracking and reporting, and project completion.

The Control factor was a material influence in the success of 13 of the 22 cases.

The post A Perfect Project highlights the value of mastering the Control factor. In this case the PM clarified and quantified the project’s goals and measured project performance against those goals on an ongoing basis. She developed and managed a risk plan that resulted in some pragmatic changes in approach to improve quality and value and she controlled the development of the application through a number of phases and rolled out in stages to reduce risk and accelerate business value. The project was hugely successful. It delivered on plan and within budget and the high quality of the implementation was confirmed by the standing ovations the PM received as she travelled across the country introducing the new environment. It also won the Conference Board of Canada’s ITX award for technology innovation and excellence. The ROI calculated by the judging committee was about 800%.

In the post You Get What You Pay For, the entire organization was surprised when the $20 million first release was a disaster that had to be pulled from production. Aside from the fact there was no formal stakeholder group to guide the way and monitor progress, the two PM’s didn’t use effective   controls on risks, quality, issues, changes or team performance. In fact, the product from the selected vendor had two major deficiencies – their systems needed major modifications to handle individual pension records across organizations and they had never co-sourced a solution before. The latter fact did not come to light until the first phase implementation failed.

On a positive note, the project highlighted in Ten Winning Project Management Practices implemented and applied control practices effectively throughout the initiative. From a financial point of view, good planning and good controls were in place. The nursing units had a positive experience with the ‘Last Call Walk Through’ process, which provided an opportunity to provide quick fixes and quick wins. The biweekly status meetings with stakeholders and the monthly milestone summary sheets were very helpful. The project was deemed a highly successful undertaking by all stakeholders and provided the learnings and foundation for Digital Imaging rollouts to the other hospitals in the region.

Takeaway: over the course of a project, stakeholders will encounter many variances between the plan and actual results and will have numerous decisions to make. The Control factor is the catalyst for those decisions. It is the compass that tells the team where it’s headed. As Yogi Berra once said “If you don’t know where you are going, you will wind up somewhere else.”

Communication

The Communication factor deals with the ongoing practices and decisions that will ensure all participants in the change are fully involved and informed in a timely manner concerning the progress of the project. Sponsors, change agents, targets and champions all have a stake in the success of the project and therefore have a significant interest in the Communication factor and the two decision areas, monitor updates and monitor feedback.

Communication isn’t just about sending out periodic status reports. It’s about fostering a multi-way dialogue, ensuring stakeholders get what they need, in the format and medium they need, in a suitable time frame.

The Communication factor was instrumental in the success or failure of 20 of the 22 cases.

A good example of a project that covered the Communication factor with aplomb is the previously mentioned Ten Winning Project Management Practices post. The strength of the project, and a major contributor to its success, was communications, including:

  • The regional bulletin, a key communiqué to those in the field.
  • The community sites had direct ownership of the communication plan at their site.
  • The stakeholder and target audience analysis laid the foundation for getting the details on identifying all the training targets. 
  • Different strategies worked at each site, according to their needs.
  • The Leadership forum (regular monthly meetings of the Diagnostic Imaging Managers) worked well to promote agreement and standardization across the regions. 
  • The eRoom provided a central online repository for the current and archived documents, readily accessible to all project team members.

Another example of the power of a well-managed Communication factor is the project reviewed in the post Speaking Truth to Power. The new contract PM assumed responsibility for a project due to be delivered in nine months. The project reported a Green status – everything going according to plan – from its inception. He found that there was no believable plan in place, no risk plan, incomplete testing and acceptance plans and inadequate resourcing. In short, there was absolutely no justification for a Green status.

At the end of his first week on the job, the contract PM filed his first status report, with a status of RED. That colour would grace all the status reports for the following ten weeks. That got the stakeholders’ attention and earned him a good deal of stakeholder wrath. Gradually, he was able to get them to agree on project scope, develop a comprehensive plan to deliver on target, get the right resources and, after almost three months on the job, report his first Green status. He also adopted a project reporting scheme that objectively determined the status colour and ensured the stakeholders were on side with the criteria used. That took some executive heat off him in the second and third months and encouraged the decision makers to focus on the issues rather than his judgment.

As the ultimate testimony to his achievement, his project was the only one of the nine initiatives in the program to deliver on plan!

Takeaway: you can do a wonderful job getting the stakeholders engaged, project dimensions agreed to, the right assets lined up, the relationship of the project to the broader business plan clarified, a comprehensive plan and resources in place but if you don’t manage the Communication factor, your project will probably fail. The Communication factor is the glue that holds everything else together. It’s a force multiplier!

The Way Forward

A number of organizations and individuals have researched project performance over the years to identify the magic formula for project success. The table below shows a sample of the findings on the top eight factors contributing to success or failure. The Standish Chaos studies have been running since 1994. Professor Ryan Nelson of the University of Virginia has been studying project performance results over a number of years and identified the top reasons for failure garnered from 99 project reviews. He’s not alone in his findings. The results are very close to the successes and failures we’ve uncovered above and in the previous post when we looked at our 22 case studies as summarized in the Project Times column below.

DrewSept26th1

You will notice that the top nine Project Pre-Check factors we’ve looked at in this two post recap address each of the success factors from a number of different perspectives. There are also nine more factors in Project Pre-Check that we haven’t covered that add additional diligence to the project experience. Effective stakeholder management ensures that all factors with the potential to impact project success are addressed and monitored collaboratively and consensually.

So, you have a choice, as a sponsor, change agent, target or champion. Proceed according to these findings and your projects will be much more successful and the experience will be a rewarding one. Ignore these findings and join the ranks of stakeholders who were too busy to learn from the experience of others. More often than not, their projects failed. That’s why Project Pre-Check is a great place to start your project. It supplies a terrific best practice based framework for building an effective guiding coalition that will be there when conflicts and crises arise to ensure your projects are done well.

In the interim, if you have a project experience, either good or bad, past or present, that you’d like to have examined through the Project Pre-Check lens and published in this blog, send me the details and we’ll have a go. This month, if your project is selected and published, I’ll send you a free copy of my latest book, Project Pre-Check FastPath – The Project Manager’s Guide to Stakeholder Management.

Don’t forget to leave your comments below.

Projects Done Well, a Recap – Part 1

Written by Drew Davison on . Posted in Articles. 12 Comments on Projects Done Well, a Recap – Part 1

FEATURESept12thOver the last two years, we’ve looked at 22 case studies in this blog. They were real projects. Some were wildly successful. Some were miserable failures. What were the key factors that contributed to those successes and failures? In this post, Part 1, we’ll start the review with a look at three of the nine most influential factors that contributed to those project outcomes. We’ll also suggest how you can leverage these findings to improve the performance of your own projects. In the next post, Part 2, we’ll complete the review of the remaining six factors.

The MethodologyDrewSept12th1

We analyzed the 22 articles presented in the From the Stakeholder’s Desk blog on Project Times against the 18 Factors in Project Pre-Check’s Decision Framework. The Decision Framework helps stakeholders form and articulate a common vision for a planned change from inception through completion. The stakeholders need to consider each of the four domains – all aspects of the change itself, the environment within which the change is being implemented, the assets that can be leveraged or that will be affected, and the way the project will be conducted.

The Findings

The good news – nine of the eighteen factors were identified as critical to the project outcomes in ten or more of the cases as shown in the graph below. The message: get your stakeholders agreeing on these factors first and your project has a much better chance of achieving its goals.
That isn’t to suggest that the other factors are unimportant. The Quality factor, the Investment Evaluation and Current/Future State factors and the Organization factor were material contributors to the outcomes on three or more of the projects we looked DrewSept12th2at. However, we believe the significance of the other factors will be situational, depending on the nature and characteristics of each unique project. The nine factors identified here as the leading contributors will have a much broader impact. Pay special attention to them.

Let’s take a closer look at three of the factors and some of the projects they influenced, either positively or negatively.

The Change Domain

The Change domain focuses on stakeholder decisions regarding the specifics of the change itself. It includes the dimensions of the change initiative, the quality needs and expectations that must be satisfied, the investment decisions behind the change and the stakeholders and their capabilities.

The two Change domain factors that stood out in our review were Stakeholders and Dimensions:

Stakeholders

The Stakeholder factor was a key contributor to project success or failure on all 22 cases. In fact, not one project with an effective stakeholder group failed. So, what is a stakeholder? Stakeholders are the decision makers on the project. They are the keys to project success. Without the right stakeholders on board, your project won’t be successful. Period! In fact, the fundamental premise underlying Project Pre-Check is this: if the stakeholders for a given change are actively involved in and agree with each decision, and all the vital decisions are addressed, the project will be successful.

Project Pre-Check uses a stakeholder model with the four roles shown at the left; sponsor, change agent (project manager), targets and champions. The sponsor, change agent and target roles always need to be filled. The champion role is desirable butDrewSept12th3 optional. Let’s take a look at how the stakeholder group helped or imperiled project success on a few of the case studies.

My last post, You Can’t Always Get What You Want, is a perfect example of what can happen when the balancing influence of the other stakeholders isn’t available to override the ego of a tyrant. The PM formed the stakeholder group at the start of the project but didn’t keep the members engaged over time. The project failed. The post Collaboration in a Command and Control World is another example of the destructive power of a tyrant. In this case, the stakeholder group was never formed and the sponsor attempted to intimidate by edict. That project failed as well.

Sometimes, a steering group is formed to guide a project but the roles and responsibilities aren’t clear and the results tend to reflect that uncertainty. In the post The Offshoring Challenge, Part 2, a multi-million dollar, mission critical undertaking, lack of clear roles and responsibilities in the steering group resulted in lots of back stabbing and finger pointing when things went wrong, and they often did. On top of that, the real sponsor wasn’t engaged and driving the change forward and the designated sponsor really wasn’t. You can’t delegate sponsorship! Eventually the roles and responsibilities were addressed, the right players were engaged and the project got delivered, but months late and millions over budget.

On the positive side, the posts Delivering Portfolio Management Light and A Perfect Project show the kind of successes that can be achieved with a fully formed and engaged stakeholder group – a lead-the-way sponsor, committed and aggressive targets who look after their own organizations’ interests and a change agent who facilitates stakeholder decision making from project inception through completion.

The takeaway: make sure you have your stakeholder group in place and engaged up front and throughout!

Dimensions

What the heck are Dimensions? Dimensions define the breadth and depth of the opportunity or problem being addressed and includes the burning platform, the business problem, need or opportunity, business goals and objectives, worth (what the organization is willing or can afford to spend), requirements, benefits, locations targeted, target dates and rationale, phasing and staging opportunities and expectations, assumptions, success criteria and volumes, transaction mix and peak periods.

The Dimensions factor was central to the project outcome in 21 of the 22. The only case where dimensions didn’t overtly influence the outcome was The Offshoring Challenge, Part 1. The dimensions were known but there were so many other gaps on the stakeholder front, resourcing, risk management, etc., the project went down in flames.

One project that suffered from a “dimensional” gap was covered in the post, The Never Ending Project. It had huge stakeholder issues which may explain why they also had difficulty defining requirements, no sense of the project’s worth to help guide decision making and no understanding of the phasing alternatives to help reduce risk. The project was years late and over four times the original $7 million estimate, with less functionality.

There are other examples of “Dimensional” gaps. The project covered in Eight Steps to PPM Implementation Success didn’t uncover the root causes of business unit discontent until after the Project Portfolio Management effort was terminated. Poor project management practices accounted for over half of the business unit complaints. Limited availability of certain IT skill sets was responsible for almost 40% of project delays. Lack of a comprehensive standard technology infrastructure resulted in significant custom work, increasing costs and risks and adding further delays. PPM would have contributed some value but it wasn’t even in the top ten action items identified.

Sometimes Agile Isn’t covered a similar problem – no clear understanding of the problems that needed to be solved. This project was actually four different changes grouped together. If the stakeholders had actually understood the problems being addressed by the four changes and explored the assumptions around each one and the four together, I expect a very different structure and approach to the problems would have been used. The project was cancelled with over $ 1 million in staff and contractor costs down the drain.

One of many projects that nailed the Dimensions and delivered successfully was covered in the post Avoiding New Technology Risks. The stakeholders knew explicitly what problems they were trying to solve. They figured out what the project was worth to the organization which led to the selection of an appropriate and affordable solution. As well, identifying a business based phasing and staging approach right up front helped iron out the new technology wrinkles and manage the risks effectively. It was a project well done!

The takeaway: ensure your stakeholders have fully addressed the Dimensions decision areas and that they are fully in agreement and stay that way throughout the project.

The Environment Domain

The Environment Domain addresses key dimensions of the current state enterprise infrastructure, the future state target architecture and the business plan that will move the enterprise from the current state to the desired future state.

One Environment domain factor, business plan, was identified with project success in our review.

Business Plan

The Business Plan factor includes eight decision areas: mission, vision, core values, strategies, enterprise priorities, dependencies, programs and timing. Stakeholders need to understand a project’s relationship to each of these facets to ensure consistency of direction and ongoing success. Any dichotomies between the stated directions and beliefs and the impact of a planned change need to be addressed as part of the project.

The Business plan factor was integral to project outcomes in 12 of the 22 cases. Here are some examples:

In the post Pulling the Project Plug, the project was deferred because it had a lower priority than other in-progress projects. Of course, the fact that the initiative had no sponsor and no stakeholder group to assess its relevance and priority was a key contributor to its demise. The end result was wasted millions of dollars and the time of critical resource required by other higher priority projects.

Conversely, in Speaking Truth to Power, the PM knew the project was a high priority, government mandated initiative with significant financial penalties for failure to deliver on time. He leveraged the CFO’s wrath over the lack of progress to secure the right staff, with the right skills at the right time to get the project delivered on time.

The takeaway: your stakeholders need to be fully aware of your project’s relationship with the culture, plans and activities of the larger organization and ensure your project is positioned appropriately.

The Way Forward

The stakeholder group is a most powerful force for enlightened project guidance and an essential resource for project managers. But it needs to be nurtured and cultivated from project inception through completion. That’s why it’s central to Project Pre-Check’s model, processes and Decision Framework. We’ve seen how the three factors covered in this article are central to project success. In the next post – Projects Well Done, a Recap – Part 2, well look at the other six factors and how they contribute to project outcomes.

In the interim, if you have a project experience, either good or bad, past or present, that you’d like to have examined through the Project Pre-Check lens and published in this blog, send me the details and we’ll have a go. This month, if your project is selected and published, I’ll send you a free copy of my latest book, Project Pre-Check FastPath – The Project Manager’s Guide to Stakeholder Management.

Don’t forget to leave your comments below.

As a Project Sponsor, What is Your Documentation Risk Tolerance?

Written by Mark A. Monteleone on . Posted in Articles. 10 Comments on As a Project Sponsor, What is Your Documentation Risk Tolerance?

To almost quote Shakespeare’s “Hamlet” – to document or not to document, that is a risk question.  This article is a follow-up to the BATimes publication, “Verifying Requirements Documentation.”  As author of the article, I took special note of a readers comment on providing organizations a continuous process improvement model on composing a business requirements document (BRD).  The comment was:

“… I too found some things worth cutting and pasting into some training or checklist material. The post script was prophetic – the environment for BRD seems to be getting squeezed by those who find the whole process “too cumbersome” and not (lowercase) “agile enough”. I know of lots of orgs whose risk tolerance is so high that they could never see the ROI in it. I Think much of the great material here could be better digested by some organizations if one applied it as part of Continuous Process Improvement. As you find cause to question your BRD effectiveness, compare your process for creating brd documents to this model. While few organizations are willing to invest in all of this effort up front (and it can be appear to be oppressive), laying this out as the gold standard sets the bar for where you can go. When flaws are found or systems don’t meet expectations, the project closure efforts should certainly involve looking at the shortcomings, comparing to this list and considering what additional pieces should be included next time to avoid the flaws, increase acceptance, or implement a solution that’s more relevant to the customer….”  #Tony 2012-01-25 22:20
This comment caused me to pause and wonder if one could construct a BRD risk tolerance model based on the contents of the BRD.  In other words, what is the risk tolerance if only certain best practice components are included in the BRD?  And can the BRD risk tolerance be represented as a sliding scale.  The purpose of this article is to propose a risk tolerance model as a sliding scale based on what is included in the contents of the BRD.

What Makes a Project Sponsor Approve the Business Requirement Document?

Risk tolerance.   The project sponsor signs-off the business requirement document when the document matches or surpasses the risk tolerance of the sponsor.  Note risk tolerance is relative to the sponsor and changes depending on the risk of the project.  For example depending on the size of the company, a $10M project motivates the sponsor to have a much lower risk tolerance than a $10K project.  Project sponsors could cite several other reasons for variable risk tolerance such as project complexity, resources, etc.  The follow-up question and point of this article is:  Can portions of the BRD be equated to various levels of risk tolerance?

A Proposed Business Requirement Document Risk Tolerance Model

Below is a BRD Risk Tolerance model (Figure 1).  It depicts a cumulative risk tolerance incline starting from a high-risk tolerance (lower left corner) to a low-risk tolerance (upper right corner).  Supporting the risk incline are seven best practices for writing a BRD.  Under each best practice are key words describing the practice; for details see “Verifying Requirements Documentation” (1).  On top of each best practice is a cumulative risk tolerance percentage.  This percentage represents the cumulative risk the project sponsor assumes when BRD components are missing.  For example, a risk tolerance of 50% equates to signing-off a BRD with all the best practices above the percentage (data requirements, transitional requirements, and traceability) missing from the BRD.  Note that for every missing BRD component the probability of defects increases in the deliverable.

MarkAug22nd

Figure 1. Business Requirements Document Tolerance Risk Model

First a Note on Project Risk

Before reading the below examples, note the percentages on the model are the sponsor risk tolerance for a project equated to “allowed” missing BRD components.  As stated before, project risk depends on the characteristics of the project (i.e., size, complexity, cost/benefits, technology, resources, duration, etc.).  The point here is that the project risk may well influence the project sponsor on what is an acceptable BRD.   

BRD Risk Tolerance Model Examples

Below are examples of BRD risk tolerance using the model in Figure 1.      

  • A project sponsor may well be justified assuming a high-risk tolerance with the BRD missing various components for a project entailing a small modification to an existing system (i.e., the cost of the BRD should not exceed the benefit of the modification).  
  • A project sponsor could assume a low-risk tolerance missing any components in the BRD for a project providing a strategic new service for the business (i.e., product defects will have a major impact to the business).  
  • If a project sponsor decides to accept a BRD with only process improvement targets and functional requirements documented, the sponsor assumes a risk tolerance of 70% (i.e., still assuming considerable risk of defects in the product or service).
  • And so on up and down the risk tolerance incline.    

BRD Risk Tolerance Model Use

The business analyst can possibly use this model as a guide for management on the level of risk assumed when approving a BRD.  On almost every project, there is a question on how much to document in the BRD.  The answer lies within the range of the project sponsor’s BRD risk tolerance.  Using this model, the business analyst can associate the BRD components with levels of risk tolerance.  With this model plus the characteristics of the project, the project sponsor has enough information on the appropriate risk to assume. 

MarkAug22nd2

Can This Model Be Used on an Agile Project?

Agile projects do not generate a formal BRD.  User stories are the basis for iterative development.  However, the product owner (sponsor) needs to consider risk tolerance when reviewing the product backlog and during the retrospective prior to approving the product release.  Questions to consider:

  • Are process improvements targets addressed?
  • Are specific functional requirements present?  Are they being addressed in business value order?  Are dependencies considered?
  • Are nonfunctional requirements measured?
  • Are the business rules incorporated within the software decisions, access authorizations, and conditions?
  • Are data relationships and cardinalities present in the files?
  • If replacing a legacy system, are transitions planned?
  • Are the original scope features reflected in the user stories?  Can cost/benefits be linked to the deliverables? 

Summary

What is your opinion of the BRD Risk Tolerance model?  I invite your comments.  Perhaps you prefer a different component order or a different level of percentages on the Cumulative Risk Tolerance line.  If you are a project sponsor needing to know what best practices should be used in a BRD, see the article cited in the reference.   

References

  1. Monteleone, Mark (2012), “Verifying Requirement Documentation,”      

Don’t forget to leave your comments below.

Effective Communications

Written by Patti Gilchrist on . Posted in Articles. 11 Comments on Effective Communications

The performance reporting process collects and distributes performance information, such as project scope, schedule, cost, quality, risk, and procurement.

The key to successful communications is asking stakeholders what they need communicated to them, and then follow through and provide it to them. I have heard many new project managers complain of “backseat drivers” on their projects, always going around them, asking team members for status (i.e., asking “are we there yet?”).

I suspect the reason for this is that many project managers act as if project status is top-secret, classified information that only the privileged few with top-secret clearance can receive. Consider that the project is operating on a “need to know” basis and your stakeholders really need to know. Mark it as confidential if you are so inclined (or if it is appropriate because you are actually dealing with confidential or sensitive data), but send out accurate and timely communications on a regular basis.

By managing the work and reporting the progress regularly to stakeholders, you will avoid the “backseat driver” syndrome.

Another benefit of this is that you will create the environment for the team to do their job uninterrupted without numerous disruptions from various stakeholders asking for status updates because you fail to provide updates sufficiently. If this is happening on your project, know this: it is the project manager’s fault.

I’ll share a story from my career.

In my colleague’s haste to leave the office for vacation, she failed to update a stakeholder on a critical deliverable that was due at the end of the day. I happened to be at the wrong place at the wrong time and became the unintended recipient of his frustration. He was extremely agitated and looking for anyone who could give him an update. I was able to get an update for him in less than five minutes and he had the information he needed and the assurance that his deliverable was on target. For something that took so little time and effort, it created a lot of unnecessary stress, frustration, and ill will. So ask yourself, is it worth it?

It is remarkable how many failing projects I have seen rescued throughout my career by improving communications and reporting. In many cases, beginning project managers did not understand their role and were not collecting or disseminating the information accurately or in a timely fashion. The work was in fact being completed; however, it was not being managed, thus timely handoffs (i.e., for dependent tasks) were not occurring between project team members. Nor was there any evidence of progress being presented to stakeholders. Therefore, stakeholders had the perception that the project was way behind schedule and they reported as such to their management. Of course, this causes a rippling effect of escalations. As soon as an experienced project manager reigned in and managed the team and got a handle on the work actually being accomplished, status was adjusted to reflect accomplishment accurately, handoffs between project team members occurred, and the project quickly was back on track. Performance reports present evidence of the work. Without them, how will anyone really know what is being accomplished along the way? The team works hard. It’s your job as project manager to ensure this is reflected in your performance reports.

Don’t forget to leave your comments below.

How Successful is Your Own PMO? Take the 5 Question PMO ‘Acid’ Test

Written by Peter Taylor on . Posted in Articles. 12 Comments on How Successful is Your Own PMO? Take the 5 Question PMO ‘Acid’ Test

Who

‘Call up your CEO and then count the number of seconds before he recognizes your name…’
If your PMO is really connected to the business, at the right level and with the right profile, then your CEO will know you and your PMOs work. You don’t have to start with the CEO, you can try this out moving up the organisation level by level – who at two levels above you knows you and the PMOs work? For those that do say ‘thanks’ and for those that don’t; well tell them about it.

What

‘What happens when you call up a project manager do you get straight through or do they adopt an avoidance strategy…’
A call from any member of the PMO should be a welcome event and not something to hide from or fear. Consider if there are certain individuals or teams or departments that are resistant to what the PMO is trying to achieve. Ask yourself why this is and plan a charm offensive to demonstrate that the PMO is their friend.

When

‘When was the last time that a project manager contacted your PMO asking for some form of help? …’
If this has not happened in some time then perhaps your PMO is not as accessible and open as you may wish it to be? Run a survey or open session to gain some insight in to the reasons for non-contact with the PMO. It may link to the ‘what’ question above i.e. fear of the PMO, or it may be just a lack of awareness. Go out of your way to help key people, regardless of if it isn’t really in your PMO remit – by winning influential supporters the word will spread about the PMO being a ‘go to’ group.

Where

‘Do people ask many times over where they should go for project information or project help…’ 
The PMO should be the automatic first call for anything project related when project managers or others need some guidance, make sure yours is easy to access and quick to respond.
Market what the PMO does, create a menu of service items that the PMO can deliver ‘off the shelf’ and advertise this tirelessly.

Why

‘Do people ask why they should use the PMO and do they know what your PMO does…’ 
You should have marketed the value of your PMO throughout the organization and people should easily access a ‘service menu’ or what the PMO can do to help them. Success stories really help here with proven benefits of PMO involvement, invest your time in developing some and get people outside the PMO to write them or at least validate them.

How

And finally question number six – the ‘how’ – how can you improve the PMOs’ work and profile, its performance, its acceptance and its role in your company?
How can you do this?  You need to think and plan and act.

Don’t forget to leave your comments below,

Peter Taylor’s background is in project management across three major business areas over the last 26 years, MRP/ERP systems with various software houses and culminating in his current role with Infor, Business Intelligence (BI) with Cognos, and product lifecycle management (PLM) with Siemens. He has spent the last 7 years leading PMOs and developing project managers and is now focusing on project based services development with Infor.