Skip to main content

Tag: Communication

The Power of Effective Communication

Written by Kiron Bondale on . Posted in Articles. 3 Comments on The Power of Effective Communication

There is a strong likelihood that if you have taken a project management training course within the last decade you have heard some variant on the saying that “90% of a project manager’s time is spent communicating.”  As with everything else, too much of a good thing can cause problems.

I have worked with junior project managers (as well as some seasoned ones) who focus on over communication instead of effective communication.  Their concern is that the perceived importance of information is in the eye of the stakeholder. They are concerned that, if the project manager does not provide “full disclosure” to stakeholders, sponsors or team members, the project manager’s information filtering could spawn or worsen a project issue.

This is a valid risk – a lack of open communication of assumptions, issues or risks has likely caused more project failures than scope creep or limited resource availability. 

However, to swing the pendulum from limited communication to the other extreme raises some risks.  For a sponsor or stakeholder to find some data that is of value to them, they have to wade through reams of interesting but low value (to them) information.  Additionally, drowning stakeholders in minutiae is a good way to lose their interest or attention in your project, to say nothing about reducing credibility in the project manager’s capabilities. 

While useful for sharing project information or eliciting feedback, online communication methods such as Twitter, Instant Messaging, and worst of all, e-mail can dramatically aggravate this situation.  While this information overload issue is dangerous for traditional projects, it is lethal for virtual projects as it increases the probability of stakeholder isolation or withdrawal.

So how does one determine the sweet spot for project communications?  

  1. Include a thorough stakeholder analysis as part of your project communications planning.  For key stakeholders as well as your sponsor, make sure you understand what, when & how do they wish to be get apprised about.
  2. Leverage both push & pull methods of communicating – push information that is time sensitive or requires action.  Let other information be pulled by stakeholders (unless they have specifically asked you to push it to them).
  3. Refresh your communications plan based on feedback.  Meet with stakeholders on a periodic basis to gauge if they feel that your level of communication is effective.
  4. Be consistent in communication content & structure.  This helps to reduce effort spent by team members or stakeholders in processing information and demonstrates predictability and professionalism.

I wrote in a previous article (http://kbondale.wordpress.com/2009/12/13/communication-communication-communication/) that a governing principle of project management is “Always Be Communicating” – perhaps this should have been re-framed as “Always be EFFECTIVELY Communicating”.

Don’t forget to leave your comments below

Implementing Project Management at a Functional Organization. Part 1.

Written by Jamal Moustafaev on . Posted in Articles. 5 Comments on Implementing Project Management at a Functional Organization. Part 1.

ImplementingPM1The Phone Call

About six months ago I was contacted by a senior manager of a large company who proceeded to tell me: “Listen, we know that you have a project management course and we are interested in it … But would you be able to come in and just assess what it is that we are doing wrong with projects and maybe customize your course according to the findings?” Obviously I agreed to get together with him and we arranged for a meeting.

Study Background

It turned out that his company was in the real estate development industry with strong ties to federal, provincial and municipal governments.

The organization had recently been created through a merger of several other smaller firms. Consequently, the company has experienced a significant growth in the number and size of their projects (the largest ones hovering at around $500 million). At the time, a typical company project portfolio consisted of approximately fifty ongoing projects, twenty of which were “cross-departmental” (i.e. required the involvement of five to ten or more different departments).

As a result of the above-mentioned events the company started experiencing problems in the areas of resource planning, resource allocation and project management. For example, while the employees of the company were complaining that they were too busy to fulfill all of their project and functional duties, the senior management was concerned that a lot of projects were late and the quality of final product was subpar. Furthermore, there were certain issues with proper planning of the projects, adequate project control and performance reporting. Many of the company’s flagship megaprojects were over budget by almost 50% and some of them were close to a year late.

The bottom line expressed by one of the executives was:

“There is something horribly wrong with our projects . . . we are not entirely sure what it is and where to start since there seem to be too many problems.”

Study Methodology

I suggested that we start by interviewing the cross-section of organization’s employees starting all the way at the top of the company (i.e. C-level executives) down to department heads, project specialists (the company did not have any designated project managers) and even some outsiders, including customers and suppliers.

The idea behind this suggestion was that it would be more appropriate to collect and understand people’s issues with projects and propose solutions that address these problems directly rather than come up with an “off-the-shelf”, best-practices solution. Also we believed that there is a better chance of people accepting our solutions if you can map them directly to problems mentioned by the employees. We also concluded that an informal approach to information gathering would be more appropriate for this exercise. As a result, all of the data presented in this article was collected mainly through one-on-one interviews.

Thinktank Consulting did not initially impose any standardized questions on the interviewees, but after a certain number of meetings several key issues started emerging repeatedly and therefore the rest of participants were asked to provide their opinions on these issues.

In total, thirteen department heads, seven executives, six project leads and four external people – both customers and subcontractors – were interviewed.

Study Results

The overall results of the assessment stage are summarized in Figure 1.

Summary of Results Percentage of Interviewees Who Mentioned This Problem
Lack of communications between the departments 98%
Lack of uniformity in project management approach across the departments 92%
Lack of accountability for cost and time overruns and poor quality 83%
Lack of feasibility analysis in project selection 79%
Projects are not prioritized properly 74%
Underestimation is an issue at our company 69%
Projects are frequently over budget or late (either underestimated or due to lack of skills) 66%

 

Figure 1

Communications

Coordination

We can see right away that an overwhelming number of people interviewed agreed that communication channels are not working properly – especially on large, strategic projects.

MEMORABLE QUOTES 

  • “One department makes a commitment, and another has to fulfill it”,
  • “Department A does its part on the project and then throws it over the fence to Department B”
  • “We do not recognize the interdependency of projects”
  • “I can’t speak for the entire organization, but it never happens in my department”

 

 

 

 

Analysis of the freeform comments from the interview participants suggests that there is a specific lack of project communications on large strategic projects especially during the initial stages when the scope and potential impacts of the project are being defined.

Commonality of the Project Management Approach

Also, an overwhelming majority of interviewees thought that there was a lack of commonality in training and methodology with respect to project management in the organization.

MEMORABLE QUOTES

  • “Most of the templates are department-specific”
  • “I had to use templates from my previous company”
  • “There is a uniformity when you have to get the money, but not when running projects”
  • “There is a lack of understanding on the role of a project manager”

 

 

 

A review of comments from the participants in the survey shows that running projects properly, and especially handover of the projects from one department to another, appears to be the key concerns of company employees.  

Project Accountability

Feasibility and Justification

Many of the people interviewed raised concerns about the feasibility of projects undertaken by the company in the first place. “Sometimes it seems that we take on projects just to prove that we can, and sometimes the projects are initiated by a simple ‘Wouldn’t it be cool if we could do this . . .’ ” mentioned one of the department directors during an interview.

 

MEMORABLE QUOTES

  • “There is resistance to the fair assessment of project feasibility”
  • “Unlikely to get $100K to conduct a feasibility study of a $100 mil project”
  • “We are very quick to jump to solutions”
  • “Sometimes an executive pet project will inexplicably go ahead”
  • “When approving projects, power should not equal approval. This kills good ideas”

 

 

 

 

Budgets and Timelines

MEMORABLE QUOTES

  • “Cost overruns are typically not viewed as too much of an issue” (Accountability)
  • “If you don’t have a plan, it is very difficult to be accountable” (Accountability)
  • “How can you know whether you are on time or not if we don’t document anything?” (Budgets and Timelines)
  • “We have historical data, but unrealistic timelines are still imposed” (Estimation)
  • “We artificially decrease/hide costs in order to get approval” (Estimation)
  • “Sometimes we have to hide costs in contingency” (Estimation)
  • “I can’t speak for the entire organization, but it never happens in my department”

 

 

 

Another interesting aspect was discovered during the assessment phase: the perceptions of whether the projects were on time and on budget were quite different between the senior management and the general project team members. Specifically, both department heads and executives had trouble answering the following question: “Do you feel that your projects are mostly delivered on time and on budget?” Analysis of freestyle comments, however, allowed us to understand the reasons behind this. It appears that since cost and time commitments were typically not properly recorded or tracked, it was very difficult for people not involved in the projects directly (i.e. department directors and senior executives) to be aware of their status.

We also discovered that underestimation was an issue at the company due either to direct pressure applied from above, or overly optimistic forecasts created sometimes to please the management of the company, or to obtain approval on projects that would not have been approved otherwise.

Recommendations

Guiding Principles

The following guiding principles were used for this project in general and in the process of generating the recommendations:

  • The main focus of our improvement efforts were larger, strategic interdepartmental projects, since they seemed to be presenting the most problems to the company and we wanted to “go after the big fish” first rather than scatter our efforts on trying to address all of the project-related issues at once.
  • The exact definition of what specifically constitutes a large, strategic interdepartmental project would be determined at a later stage of the overall initiative, but we definitely had an understanding that a $500 million endeavor involving ten departments of the company would most definitely fall in the “flagship project” category.
  • Major importance will be given to simplicity and user-friendliness of the processes proposed since the concept of project management was so foreign to most of people at the company. Therefore, “dropping” a full-scale PMBOK-type project management framework on the organization would probably have scared and turned-off most of the employees.
  • All proposals generated by Thinktank Consulting have to be screened, analyzed, verified and, if necessary, updated by the “focus group” of company employees with previous project management experience. This step was necessary in order to fine-tune a fairly generic set of project management processes and documents to the company’s realities.

Action Items

The following action items were given to the company based on the issues identified in the first stage:

  1. Develop a simple and user-friendly project management methodology and apply it to one or several pilot projects. 
  2. Develop a minimal number of project management templates and make their use mandatory on one or several pilot projects
    1. Project Charte
    2. Project Plan
    3. Status Repor
    4. Meeting Minute
    5. Change Request
    6. Lessons Learned
  3. Put all potential project stakeholders (including department heads and executives) through a two-day project management workshop.
  4. Introduce department-independent project managers to larger interdepartmental projects (initially to pilot project only).
  5. If the pilot projects succeed, then decide to which projects the new methodology should apply.
  6. In phases 2 and 3 move into program management/strategic resource planning and ultimately towards project portfolio management (see Figure 3)

Note: Although a “Business Case” document should initiate the project management methodology chain, it was decided to postpone the implementation of this step until Phase 3 – Portfolio Management implementation. This was because the organization already had a project selection procedure, albeit somewhat deficient.

Look for Part 2 of this article in an upcoming Project Times

Don’t forget to leave your comments below

Jamal Moustafaev, MBA, PMP – president and founder of Thinktank Consulting, is an internationally acclaimed expert in the areas of project/portfolio management, scope definition, requirements analysis, process improvement and corporate training. Mr. Moustafaev is author of “Delivering Exceptional Project Results: A Practical Guide to Project Selection, Scoping, Estimation and Management” (released by J. Ross Publishing in September 2010). He is also the author of various project management and business analysis webinars delivered in partnership with Project Times:

In addition to teaching a highly acclaimed “Project Management Essentials” course at British Columbia Institute of Technology, Mr. Moustafaev also offers the following corporate seminars through his company:

“Practical Portfolio Management – Selecting & Managing The Right Projects”
“Successful Hands-On Management of IT and Software Projects” 
“Successful Hands-On Management of Modern-Day Projects” 
“From Waterfall to Agile – Practical Requirements Engineering”  

For further information, please contact: Mr. Moustafaev Phone: 778-995-4396 

E-mail::[email protected]  Website: www.thinktankconsulting.ca

Mindfully Managing Expectations

Written by George Pitagorsky on . Posted in Articles. 5 Comments on Mindfully Managing Expectations

Last month I wrote about the place for pushback in managing expectations in projects.  As comments pointed out, it is not just push back that is needed.  Push back is one factor among many.  When we do find the need to push back it must be done consciously as a part of the overall process of managing expectations and within the context of meeting project objectives in the most effective way. 

Clearly, the expectations of stakeholders, both those with power and those without, have a significant effect on project success and the degree to which the project is faced with unnecessary conflict and performance shortfalls.  Sponsor and client expectations of delivery of something on some date within some budget must be informed by their awareness of project risks and complexities.  Where expectations do not consider risk and change, there is a pressure that is created to do the “impossible” or suffer the consequences.

This pressure can be quite powerful as a motivator but too much of it or the wrong kind will have negative effects.  What is the right balance?  When does pushing the edge or stretching to optimize performance become a dysfunctional charge into trying to do too much too quickly and for a bargain cost?

How Do We Manage Expectations? 

The first step is to take a step back from ourselves and assess stakeholders’ perceptions, needs, desires and mental models.  In a project everyone has expectations. 

Expectations drive performance; committed people work to meet their own expectations and the expectations of others.  If the expectations are “stretch” then performance may tighten up and extra effort will be applied to hit targets.  Lessons learned will enable future projects to be more optimally performed.

In the body, if the stretch is too much a muscle gets pulled.  Personal performance degrades, at least until the muscle heals.  If there is not enough stretch there is tightness, rigidity, slowness, increased danger of pulling muscles and reduced capacity to stretch.

Projects are like bodies in this way.  Too much stretch and there is dysfunction – burn-out, taking unwise shortcuts, lost opportunities and in many cases unmet expectations.  Too little stretch and project targets may be met but costs and performance efficiencies across multiple projects will suffer as will the ability to hit performance peaks when needed.

Expectations are Thoughts

They represent what we want to have happen and think can or will happen?  Underlying expectations are assumptions regarding how the project will play out to deliver the desired outcome.   A key assumption supporting healthy expectations is that there is uncertainty and that the more complex and hostile the working environment is, the greater the uncertainty. 

To manage expectations, we facilitate so that everyone is aware of and tests the validity of their expectations.  Then we can work to get a mutual agreement regarding objectives, product scope and the work itself.  Work is realistically scheduled; costs are estimated; risks, the inevitability of change, environmental and resource constraints are understood; project performance and management processes are defined; roles and responsibilities are understood and used as a basis for accountability. 

These are the major factors that, when brought together, establish stakeholder expectations.   Expectations drive performance and establish the benchmark for project success.  Make sure they are rational:  What is the likelihood of their being met, given expected resources and conditions?

Don’t forget to leave your comments below

Writing Better Project Charters

Written by Simon Moore on . Posted in Articles.

betterprojectchartersA project charter is a critical document in that it authorizes the start of a project. Unfortunately it is sometimes viewed as a formality in the rush to get a project started. The costs of rushing the project charter will be felt later in the project with greater role ambiguity, slower decision making and lack of focus. The project charter serves as a reference throughout the life of a project and even in the subsequent post-mortem. The project charter is a formal deliverable that should not change, unless there is a significant change in the project itself, which, of course, should be detailed in the risks and mitigations section of the project charter. It is important because the project charter must be approved by the project sponsor, granting the required resources for the project.

Given that project charters are such important documents, here are some tips for writing better project charters, which will result in better project performance:

Clear Project Goals

“Management by objective works – if you know the objectives. Ninety percent of the time you don’t.” Peter Drucker

Charters typically start with the project name, but far more important is the project goal. What exactly is the project setting out to achieve, and what does success look like? Be crisp about this; the goal should be less than a paragraph, ideally a sentence, and ideally refer to key performance indicators later in the document. For example, “Upgrade our IT systems” is not a clear goal.

  • Who are the systems being upgraded for?
  • To what version?
  • When will this be finished
  • For how many users?
  • Is it merely upgrading, or does scope extend to training and usage?
  • Will the system be customized, based on user feedback or deployed without modification?
  • Will the project include any ongoing support?

A clearer goal is “Enable the 135 employees within PPMCo’s accounting and financial departments to perform SEC compliant project based accounting for the 2011 fiscal year, and train the 135 employees so they are able to maintain and support the new process themselves.”

Firstly, the goal doesn’t have absolutely all the answers, but it sets things up well for detail later in the document. You’ll also notice that the example goal above does not include the IT system itself, that’s intentional, just deploying the IT system will not meet the goal, the goal is to improve accounting within the organization, not simply to roll out a new piece of software. It has been determined that the IT system is the way to reach the goal, but not the goal itself. This is a critical distinction, and the project charter should make this distinction.

The Dialogue is as Important as the Charter that Results

A significant part of the value of a project charter results from the dialogue that should surround its creation. Ideally, the project charter is the summary of a round of critical discussions. Since the project has not begun when the charter is written, it gives a great opportunity to discuss potential trade-offs before the project starts. This is typically a much better time to have the discussion because the pressure is much reduced when there is no angry client, sub-contractor or supplier phoning, emailing or knocking on your door. By having these discussions in advance they are much easier and a number of problems can be avoided before they even occur.

For example, is it more important to finish a week earlier or save $20,000? Is user satisfaction more important than consistency with other systems within the organization? Is the director of finance to be held accountable or consulted for a particular task? Bear in mind that this is the document the project sponsor puts their signature on, so it carries a lot of weight and can be used to lay out the framework or decision structure for as many decisions as possible in advance.

This may feel like overkill and an unnecessary burden, but remember that the project manager will have much less time once the project is in flight, and the project sponsor might be on vacation or in a different time zone as key uncertainties arise. Taking time to be thorough in production of this document will pre-empt as many potential issues as possible. It will save a great deal of time once the project is in progress, because rather than kicking off a series of meetings to solve a problem, onc can simply refer to the project charter for many answers about scope, roles, trade-offs and so on. The project charter will also empower decision making by the project manager, because the needs of the project sponsor are set out in the document.

Define Roles

“Be candid with everyone.” Jack Welch

Any project charter should define roles, but there is an opportunity to be clear on what those roles really mean, rather than just citing job titles. There are many frameworks for doing this. I recommend using a PACE framework to define roles. PACE stands for the roles within the framework (Process driver, Accountable, Consulted, Execution):

Process Driver: The responsible party does or assigns the work for a particular task and makes decisions after consulting with the accountable party. The process driver has a close relationship with the accountable party, who can veto their decisions. The process driver assigns work to those in execution roles and engages with those in consulting roles.

Accountable: The accountable party signs off upon completion of the task. The accountable party will work closely with the process driver and is more powerful than the process driver in that they can veto their decisions.

Consulted: Participates in two way communication. This group participates in decisions related to the project, the process driver makes the decision, and they should not escalate problems to the accountable party. Note that being consulted does not necessarily mean you get to make the decision, but you do have the opportunity to have a dialogue with the process driver and influence the process.

Execution: Receives one way communication and may work on particular sub-tasks An informed party gets to receive communication about what is happening. The nature and frequency of the communication should be outlined. However, the informed parties do not have the right to force any kind of decision regarding the project. For project success, moving as many parties from the consulted to informed group as possible will help speed communications.

The PACE model can either apply to the entire project if tasks are consistent, but more often the PACE roles differ depending on the tasks in question. Of course, usage of the PACE model does entail some difficult discussions up front, but it is far better to have those discussions once before the project starts than to manage ongoing ambiguity in relationships and roles as the project progresses.

Identify a Mitigation Strategy for Each Risk

“Risk comes from not knowing what you’re doing.” Warren Buffett

Risk management should happen at every stage of the project, including the project charter. Whenever a risk is identified, a mitigation strategy should also be identified and this should happen as early as during the project charter. Merely identifying risks without any thought for mitigation, should it occur, has limited value. Once again, this is a valuable opportunity to empower the project manager to solve risks, rather than going back to the project sponsor, and it means risks can be resolved quicker. Of course, there is still the possibility that unexpected risks arise, but investing time in mitigating other risks will enable the project manager to better identify material, unexpected risks as they arise.

Share the Project Charter Broadly

Just as the project charter is a good opportunity to have a detailed dialogue with the project sponsor and others, it is also an opportunity to reinforce transparency within the organization and build awareness of the project that is about to launch. Rather than just pulling out the charter when a dispute arises, the project charter should be broadly shared at the inception of a project to inform people of the project’s existence. This will also save some time for the project manager, as the project charter should answer a number of questions that people might have about goals, roles and scope which they would otherwise ask of the project manager directly. Writing a great project charter entails significant time and effort on your part, so ensure that you get the full benefit by sharing the charter broadly.

Don’t forget to leave your comments below

Simon Moore is the author of Strategic Project Portfolio Management (Wiley, 2009) and the Strategic PPM blog. He holds an MBA, CFA and an undergraduate degree from Oxford University. He is a product planner for Microsoft determining international requirements for future Microsoft Business Division products including project management tools.

Stealth Projects – Why Should We Care?

Written by Kiron Bondale on . Posted in Articles. 4 Comments on Stealth Projects – Why Should We Care?

Stealth ProjectsA stealth project is an initiative that was never formally sanctioned or approved. This is not a value judgment – many stealth projects are able to deliver worthwhile business outcomes, but at what cost?

Stealth projects have been portrayed as being one of the Four Horseman of the Project Portfolio Management Apocalypse. So why do they survive (and even thrive!) in many organizations?

A stealth project usually emerges when a customer knows that their request will not be addressed in a timely fashion and leverages their position, influence or relationships within the organization to get the work done.

Likely causes for this perception are:

  • The customer may feel that the request will not be perceived by the governance committee or decision makers as being as worthwhile or as urgent as other requests that are more likely to be approved
  • The customer may feel that the work intake process (the method by which requests are submitted, evaluated and either approved or rejected) is too onerous

Another possibility is that the customer may simply not know any better. They may have been used to going to their “favorite” resource in the past to get things done, and even if a work intake process has been implemented they may be unaware of it or be purposely ignoring it. We tend to repeat past behaviors that resulted in desired results where there were no negative consequences. If there were no repercussions in the past for not following proper work intake practices, this behavior will persist.

So why should we care about stealth projects?

  • They consume human and financial resources that should have been utilized on officially approved and prioritized initiatives. No organization today has the luxury of infinite resource capacity, so there is always an opportunity cost incurred by turning a blind eye to stealth projects.
  • They may not be executed following all required compliance policies and practices. When a project is initiated as a stealth project, it is a reasonable assumption that quality or regulatory assurance practices might have been missed. The result could be that the deliverables from the project incur a heavier operational support or regulatory compliance burden than those of properly sanctioned and managed projects.

How can we identify stealth projects? Organizations that have successfully implemented time capture systems have an advantage, but it could also be as simple as managers knowing what their teams are working on, and for the management team as a whole to be committed to identifying and exposing stealth projects.

The outcome should not solely be punishment of the originators of these projects. In many cases, the customer may be unaware of the proper work intake process or may be highlighting a scalability or flexibility issue with the process.

To weed out stealth projects, a well communicated, flexible and scalable work intake process coupled with management commitment to the process is essential. However, this needs to be balanced against fostering a culture that encourages the brainstorming and submission of creative, innovative ideas.

Don’t forget to leave your comments below