Project Management 2.0

New technologies, concepts, and Web 2.0 tools are popping up everywhere. How can you use them to help your project team collaborate, communicate - or just give your project an extra boost? [Contact Dave]

About this Blog


Recent Posts

What To Expect When Your Stakeholders Are Expecting

8 More Templates to Save You Time

What's The WORST Thing a PM Can Do?

9 Amazing PM Templates

Coded Messages > What Are "Project People" Really Saying?

What To Expect When Your Stakeholders Are Expecting

Categories: Interviews

We recently had the honor of speaking with Ori Schibi, author of the book “Managing Stakeholder Expectations for Project Success”  Ori will also be a speaker at the PMI Global Congress 2014 - North America, delivering "The Role of the Business Analyst in Managing Stakeholder Expectations " So you kind of get the feeling that he knows what to expect from stakeholders.

Although most of Ori's answers imply an increase in the scope of the BA role and what appears to be additional work volume - he believes deeply that enhancing the collaboration between the PM and the BA will allow both roles to achieve more effective results with improved efficiency – resulting in less work for each overall.

Q1. How important is the role of the BA in managing stakeholder expectations? Are there ways of increasing or decreasing that importance? (Perhaps by making their power/lack of power to alter scope clear?)

The role of the BA in managing stakeholder expectations is important and can be substantial, even though this aspect of the BA’s role is often overlooked. In fact, there is a strong need for an increase in the BA’s role in managing expectations. There are multiple areas that are inherent to the BA’s role and the knowledge that the BA brings to the table that can provide significant value to the effort of managing stakeholder expectations. The areas of potential contribution span all throughout the project:

1.     Take part in performing project complexity and readiness assessments to identify early areas of deficiency or concern

2.     Take a more active role in providing information for the Project Charter, utilizing the BA’s knowledge of the business case and other early project-related due diligence activities

3.     Establish clear boundaries with the PM on who does what (in the areas of risk, quality, transitioning requirements and scope management, communication, issue management and reporting)

4.     Provide the PM with a “package” of background documentation, access information, and existing resources that are applicable to the project

5.     Take an active role in managing issues and assumptions

6.     Establish guidelines for prioritization and urgency (cross-project and within the project)

7.     Jointly (with the PM) define project success criteria and trade-offs that factor in both project and business objectives

8.     Help the PM articulate the cost-benefit and impact of actions, decisions or delays

9.     Jointly build a set of Health Measures that serve as early indicators to stakeholders of trends and warning signs before performance issues surface


Q2. What are the top 3 ways Project Managers could work with stakeholders to improve stakeholder communications?

1.     Focus (i.e. invest time and energy) in building trust, developing a rapport and establishing healthy working relationships with at least a representation of the key stakeholders (partially by utilizing the BA’s familiarity and existing relationships with stakeholders)

2.     Establish a Team Contract that outlines a set of ground rules to set expectations and serve as a code of conduct for communication within the team and with external stakeholders. This Team Contract should address three areas:          

a.    General communication

b.    Emails and messaging

c.     Meetings and teleconferences

3.     Create a Delegation and Escalation system that will free up some of the PM’s time to handle “strategic” aspects of the project (e.g. resource management, cross-project dependencies and business risks), specifically:

a.    An “internal” system (within the project team) of delegation and areas of ownership that builds a system of support for BAs and team members to handle an agreed upon set of ongoing “mechanical” responsibilities of the project (e.g. schedule management and certain aspects of reporting)

b.    A combined internal and external set of clear escalation procedures for risks, reporting, issues and controls to reduce “noise” in the system.


Q3. What role does the BA play in managing risk? Are they more able to identify risks than the Project Manager?

The BA has the organizational and product knowledge, as well as exposure to project related processes and activities that enables the BA to make an even greater contribution to managing risk than even the PM.

The BA’s involvement in risk management should focus on three categories, depending on the project’s needs and on the BA’s level of experience:

1.     Requirements

a.    Requirements management (i.e. the process) related risks – with the central role the BA plays in the requirements process, he/she needs to (and often does) lead the effort of managing risks related to and around the requirements process, and incorporate all remaining risks into the overall project risks considerations. These are mainly risks that may impact the project success criteria.

b.    Requirements and scope (i.e. the product) related risks – the BA needs to capture and introduce into the project risk management process all of the risks related to the actual requirements; i.e. risks that may impact the ability of the project to deliver product and project success. Since the PM has no clear context and visibility into the requirements, the BA is perfectly suited for integrating the requirements related risks into the project.

2.     Project risks – beyond the familiarity with the product, the BA is also closely involved with project-related processes, team coherence and performance, roles and responsibilities, and has visibility of other issues, assumptions and constraints. Having this additional set of eyes involved in and interacting with the day-to-day project work can be handy in providing the PM with alerts and help the process of managing by exception.

3.     Context for business/operational risk – with the PM typically focusing on project risks (surrounding the project success criteria), many of the PM’s decisions may be “good for the project”, yet at times be misaligned with business objectives and/or existing operational issues, or ones that may be triggered by project decisions (e.g. reducing the testing time to achieve schedule milestones, which may increase the risk for defects and other post implementation issues). In this case the BA can serve as the “voice of reason”, resulting in better likelihood to address both project and business related risks and considerations.


Q4. What role does the BA play in managing quality? How is that best clarified in the requirements they produce (both written and verbally communicated)?

The BA should, along with the PM, own quality. The BA is the most applicable person to lead the effort to pursue quality and in turn ensure that the PM maintains a focus on quality. Quality is the key to achieve a combination of product quality, project success and customer satisfaction – and the BA has the most applicable knowledge of these areas.

The way to achieve quality is by integrating all relevant considerations into the project decision making process. Working with the PM, the BA should provide an impact assessment of actions and decision on the product and on any downstream areas – with a focus on business value and post project impact.

More specifically, the BA should lead the enhancement of the quality assurance role (e.g. audits, reviews, process analysis), lead the way in producing project health measure indications, and incorporate cost of quality analysis to ensure impact is expressed in terms and values that resonate with stakeholder needs.

The BA plays an important role in producing quality through the requirements. With over 40% of project defects traced back to the requirements, owning the quality starts with producing requirements that are SMART-CUT (Specific, Measurable, Attainable, Realistic and Time-bound; Clear/Complete, Unambiguous and Traceable). Applying the notion that “quality needs to be designed into the product and not inspected into it” makes it the BA’s role to take quality seriously from day one and ensure that no requirement makes it into the project if it’s not ready to go. Further, it is the BA’s responsibility to ensure that the requirements “hand-off” is done properly so that each requirement is appropriately represented in the project scope, as well as in subsequent planning.

Conceptually, the BA should deal with, if not own, all of the “invisible” aspects of quality, i.e. those parts of the quality iceberg that is under water. These “invisible” aspects are the hidden costs organizations incur as a result of poor quality; these costs are difficult to track and account for, as they are spread over time, beyond the project end date, and over multiple cost centres – depending on the areas impacted.


Q5. Could you tell us a bit about your book? Perhaps give us three things that our members might find most useful about it?

1.     “Managing Stakeholder Expectations for Project Success”is a pioneer in providing an integrated approach to managing stakeholder expectations, by offering a broad context for the area of stakeholder engagement. The book reviews and considers everything that the PM needs to do in order to effectively manage stakeholder expectations; and ultimately deliver project success. With that, the book introduces a comprehensive Team Contract that allows the PM to “own” project communication and effectively addresses common issues that often plague projects’ and teams’ performance in a meaningful and constructive way.

2.     The book focuses on what the PM needs to do and to focus on and how the PM should to utilize his/her time to maximize the value produced by working smarter, not harder. It clearly articulates common challenges and problems and provides simple and straight forward approaches to address them, establish environments that foster collaboration, overcome barriers and continuously keep an eye on project success criteria and their alignment to business objectives.

3.     The book is intended not only for PMs, but also for BAs (to enhance the BA’s ability to add value to stakeholder expectations management) and for Project Sponsors (to clarify the mandate they need to provide PMs so the job gets done). In addition to being relevant for the three leading non-technical roles in a project, the book is also a first to introduce a detailed breakdown of what project integration entails, along with full consideration and impact of dependencies and project trade-offs. Additional concepts that contribute to the reader’s ability to apply critical thinking include time management, and a mechanism to determine urgency and prioritization.

My upcoming book (no title yet) deals with how to enhance and streamline the relationship, touchpoints and collaboration between the PM and the BA and is due to be published in the Fall of 2015.

Ori Schibi (MBA, PMP, PRINCE2 Practitioner), is a visionary leader, communicator, connector, and devoted husband and father. With 24 years’ experience, he offers practical and unique ways to effectively manage projects and people. Ori is the President of PM Konnectors (, a Toronto, Canada based Consulting firm specializing in program/project management / recovery, PMOs, cost of quality measurements, process streamlining and improvement, PM/BA skills assessments and communication management. Ori is the author of the book “Managing Stakeholder Expectations for Project Success” (J. Ross, 2013; 

Posted on: August 29, 2014 06:50 PM | Permalink | Comments (0)

8 More Templates to Save You Time

Categories: New Templates

Happy August & thank you for being Members of the community!

This month, we are including 2 NEW TEMPLATES and six from our vast collection!

Don't forget you also have access to everything in the entire PREMIUM TEMPLATE library! We hope these make your life a bit easier – helping us fulfill our mission of making YOU more successful.

The following premium templates, two newly available as of this month, are available to all premium members and to ALL members through Wednesday, August 27th. 

Contingency Plan Template (NEW THIS MONTH!)
This document summarizes the contingency plan for a risk. This level of formality will not be appropriate for all risks on all projects, but is a useful tool for potentially big impact risks. Every actively managed risk requires a contingency plan even if it is not this formal. When and if the risk triggers, there will be a need for decisive action. This document needs to be clear and complete enough to allow for those steps to be taken without a requirement for further analysis. 

Project Management Evaluation Review Report and Worksheet Templates (NEW THIS MONTH!)
Project Management Evaluation Reviews are formal reviews intended to uncover issues, concerns or challenges that may impact the quality or value results if changes are not made and facilitates resolution for what needs to be improved for successful completion. 

Failure Analysis: What Went Wrong, and Why? 
Sometimes things go horribly wrong once. Other times, they go horribly wrong on a routine basis. Ever wonder why that is? If failure is a recurring theme in your projects, you'd be wise to download this deliverable. 

Enterprise-wide Analysis 
This document outlines the Enterprise-wide Analysis, which describes the enterprise application package’s features and functions, analyses on its cost-benefit and risks, and the technical requirements to be supported. 

Risk Review Process and Checklist 
Need to perform a risk audit on a project? This Risk Review Process and Checklist guides you through an exhaustive review of the effort, including documentation, resourcing, delivery performance to date, financial performance to date, and much more. It's not just a checklist of simple measures, but asks a number of questions that truly speak to the potential for the project to achieve the results that were intended. 

Requirements Completeness Evaluation Checklist 
This checklist will assist you in minimizing scope creep, schedule extensions and project failure by evaluating whether the initial requirements are complete. This series of requirements attributes, quality checks, and examples provide a thorough review of what you plan to do. 

Presenting Your Business Case to Management 
Presenting a winning business case with the right amount of the right information for the right audience is the key to getting approval and funding for your project! Here is a presentation that will give you the fine points on how to do just that. 

Common Component Change Request 
Use this Common Component Change Request Form to track all component change requests. 

Just get out of a tough meeting? Share the pain with those who were in the meeting with you - 

We hope you are having an amazing year so far and thank you again for being a member! We sincerely appreciate your support and are completely committed to your success. If we can help with anything project related, please let us know

Dave Garrett
President & CEO,

Posted on: August 18, 2014 02:03 PM | Permalink | Comments (0)

What's The WORST Thing a PM Can Do?

Categories: Advice

I recently posed this question on Quora, knowing that there are a thousand potential answers - all of them probably valid when you spin them the right way. However everyone has a favorite which is born out of their own personal experience, probably some tragic PM circumstance that produced a "worst case" result. 

So why bother with trying to identify each individual's "PM pet peeve"? Assuming each strong opinion is the result of some tragedy - this gives you a list of really important pitfalls to avoid - each of them THE most important in someone's eyes.

Here are a few responses from others. If you have a moment, please add your experience to the comment string...















Posted on: July 27, 2014 12:34 PM | Permalink | Comments (8)

9 Amazing PM Templates

Categories: New Templates

Happy June & thank you again for being Premium Members of the community!

This month we bring you 2 NEW templates as well as 7 of our existing classic templates!

Don't forget you also have access to everything in the entire PREMIUM TEMPLATE library! We hope these make your life a bit easier – helping us fulfill our mission of making YOU more successful.

The following premium templates, newly available as of today, are available to all premium members. 

Project Constraints Hierarchy Template (NEW THIS MONTH!)
The project constraints hierarchy is intended to identify the order in which constraints will be compromised in order to protect/preserve more important constraints. The constraints hierarchy should be determined in conjunction with the major stakeholders who also need to understand the implications of their decisions. 

Earned Value Management (EVM) Calculator (NEW THIS MONTH!)
The basic premise of EVM is that we can assign a value to each task. We can then determine the progress that we have made on our project relative to schedule by comparing the amount of work completed with the amount of work planned to have been completed at the reporting date, and the progress relative to budget by comparing the amount of money that we have actually spent with the amount of money that we planned to spend. 

Project Team Retrospective Survey 
The project is over. How did it go from the perspective of those who really did the work, i.e., those on the project team? Though you could use this survey for an active project, it's really applicable to a project that has just finished. Use it as part of the project post-mortem. 

System Requirements Specification
The System Requirements Specification (SRS) document describes all data, functional and behavioral requirements of the software under production or development. 

Risk Management Grid
The Risk Management Grid is a technique to identify potential risk events that could impact one of more of the project’s Seven Win Conditions. Importantly, it also serves to decide how those events will be prevented or mitigated. 

Project HEADWAY Communications Plan
This template allows the project manager to fully understand the communication needs of stakeholders on the project. Stakeholders expectations and requirements can be documented ensuring there is a clear understanding of the why, when, how and what of the project’s communications. 

Change Management Policy and Process
The Change Management process is fundamental to the successful delivery of the project. The Change Management process ensures that each change introduced to the project environment is appropriately defined, evaluated and approved prior to implementation. 

Risk Identification and Assessment Form
Use the risk identification and assessment form to assess risks to (and their impact on) a project. Types of risks to be identified using this form include scope, timescales, deliverables, resources, milestones and expenditures. 

Portfolio HEADWAY Project Plan
Organizations often undertake the wrong projects and fail to understand if the projects they choose actually provide the expected outcomes. The Portfolio HEADWAY process is a project-focused, step-by-step process that will help your organization to select the right projects, manage those projects well and, realize the expected benefits. Put Portfolio HEADWAY to work for your organization. 

Just get out of a tough meeting? Share the pain with those who were in the meeting with you - 

We hope you are having an amazing year so far and thank you again for being a member! We sincerely appreciate your support and are completely committed to your success. If we can help with anything project related, please let us know

Dave Garrett
President & CEO,

Posted on: June 26, 2014 06:44 AM | Permalink | Comments (0)

Coded Messages > What Are "Project People" Really Saying?

Categories: Advice

Being open and honest is always the best way to go with project-related transaction. However there are many many times when you, your team, or stakeholders might be speaking in code rather than just saying what they mean.

I've listed a few of those coded messages below.  


Code: "We don't have the budget for that."

Reality: "I don't think that's worth exploring."


Code: "We tried that already."  (maybe 5, 10, 20 years ago)

Reality: "I don't think that will work."


Code: "[Our Competitor] already does that well."

Reality: "We can't ever match or beat [our competitor's offering]."


Code: "This is going to cannabilize [our existing product]."

Reality: "My job or my friend's job might change or go away."


Code: "Sometimes no just means NO."

Reality: "You are not worth explaining this to."


Are there others that you know of?


Posted on: June 26, 2014 06:36 AM | Permalink | Comments (2)

Eighty percent of success is showing up.

- Woody Allen