Skip to main content

Tag: Change Management

5 Key Reasons Why Some Projects Succeed and Some Don’t

Written by Brad Egeland on . Posted in Articles. 6 Comments on 5 Key Reasons Why Some Projects Succeed and Some Don’t

It is just a fact in the project management world – some projects succeed, and some don’t.

Many studies place project failure – to some degree or another and by someone’s standards somewhere – at between 56% and 74% of all projects. I have also seen a couple of more optimistic surveys putting the success figure at closer to 54%. Still, none of those figures make any of us feel warm and fuzzy about our chances at project success. We all know that we tend to cut corners or that our methodology or process may not be the best. It is like continuing to eat fried chicken when your doctor tells you to stop for your health. We often still like to stick with what we feel comfortable with even if we know it could have (not definitely will have) negative consequences at some point later than tomorrow or next week.

That said, let’s look at five key areas that loosely fall under the logical concept of project management best practices that can, when practiced regularly and thoroughly, logically lead to better project outcomes.

1. Proper Planning

Proper upfront planning is always going to be a critical best practice that leads to project success more often than projects that lack the proper amount of planning. What is the right amount of planning? There is no yardstick for this, but it involves a combination of detailed requirements planning and documentation, setting up a proper way to regularly manage project financials and resource supply, risk and issue management, and of course, a planned and keen oversight of project scope and change control. Communication is the #1 responsibility of the project manager and helps everything else go much more smoothly. That is why I also consider a project communication plan – whether it is a formal project deliverable or just a casual spreadsheet for everyone to review and post on his or her office wall – as something that should be sent out at the beginning of every project. Yes, it is part of the planning process and ensures that everyone on the project knows who is responsible for what communication, how to contact all key stakeholders through just about any means possible, and when, where and how the regularly scheduled project meetings will be happening.

2. Close Budget Oversight

Close budget control is critical, but not practiced nearly enough. Involve the team and ensure the team is accountable for assigned tasks including the estimated effort, actual effort and the effort to finish tasks. If your team knows that you watch and manage the budget closely, then they are going to be more likely to charge their time to correctly to your project when working on multiple projects making it far less likely to charge junk time to your projects.

3. Project Team Ownership of Task

How do you get your project team to “own” their tasks assigned to them? Make them accountable for everything about those tasks. From defining them with you during project schedule planning work to tracking them while the project is in motion to reporting on their status to the project customer during weekly formal project status meetings. The sooner your can get your project team members assigned to their roles on the project, the sooner they can assist in the early project planning activities including the project schedule development and the individual task definitions and scope. Those are the tasks they will be assisting with and owning, and that planning phase helps them to feel and gain ownership of those tasks they will be working on soon and throughout the project engagement. It helps build in automatic ownership and accountability.

4. Error-Free Deliverables

Ok, perfection is not going to happen. However, you can certainly strive for it with your work and your team’s work on deliverables that go to the customer. Peer review everything to greatly reduce easily overlooked mistakes in project deliverables going out for customer review and sign off. Trust me – I know from personal experience that sending off the same great functional design document three times with errors still visible – even simply typos – can lead to a significant decline in customer satisfaction and confidence in yours and your teams’ ability to deliver quality. I corrected the problem – almost too late for one project – by requiring peer reviews by all project team members of everything that went to the customer. Everything (except for the basic communication emails, of course). Our problem was a problematic free PDF creation program, but it was sloppy for us not to be checking and just sending errors off for the customer to find. That should never happen on a customer deliverable.

5. Solid Customer Engagement

The engaged customer is the one that is available to exchange ideas, supply and receive information, provide critical input on key project decisions that need to be made and can clarify requirements or business processes on the spot when progress requires it. If the project manager can keep the customer focused more on your project than the hundreds of other things that are trying to take up his or her time, then you win that battle in making it easier to get quick info when the situation requires it. You will be able to make sure that the customer is sitting in those weekly project status meetings helping make next step plans when they come up. Win-win.

Summary/Call for Input

I could write on this topic till the end of time and never really pound home any real guarantees of project success – there are no guarantees. In the end, adhering as much as possible to logical best practices, repeatable successful processes, practices and templates, and trying not to just bring a project home on the wings of luck are your best way of ensuring project success.

What are your thoughts on this topic? What works for you? What has failed miserably? Please share your thoughts and experiences in the comments below.

OUTSIDE THE BOX Forum: On Changing Horses in Midstream

Written by Robert Wysocki on . Posted in Articles. 3 Comments on OUTSIDE THE BOX Forum: On Changing Horses in Midstream

We started out using Scrum but as we learned more about the solution we have had to adapt Scrum to the realities of the project and its environment.

After so many changes our project management model is held together by bubble gum and hairpins. It is very inefficient and ineffective as well. We are right in the middle of the project, and the solution is now known. All that is left is to build and deploy the solution.

I contend that there are situations in Complex Project Management where changing PMLC Models during project execution will be a good business decision. So for the above example, should we abandon Scrum in favor of a more traditional model? What factors should we consider in making that decision?

The Situation

The Complex Project Landscape is one where either the Solution or the Goal are not clearly defined or understood at the outset of the project. Through iteration, the deliverables converge on the final Goal and/or Solution. Then there is the acceptance of the deliverables, and that is measured by delivered business value compared to planned business value. Obviously, these are high-risk projects. It is what happens during the execution of these projects that is my interest here. First of all learning and discovery will have taken place and perhaps after some number of iterations the Goal is known (you chose an Extreme Model because the Goal was not clearly defined at the outset) or the Solution is known (you chose and Agile Model because the Solution was not clearly defined at the outset of the project). Your team is not experienced in the Model you chose originally and would be much more effective if they could switch to a more Traditional Model.

The Factors

Such a change may sound simple but let’s consider some of the factors that we will have to deal with if we decide to change PMLC Models.

Cost

There are three costs to consider:

Cost of abandonment – This will include documenting the current status of the project if a new team will be brought on board. Any contracts that may not be carried forward and will have to be closed will also be added to the cost. If any deliverables produced so far will not be part of the final solution, there are sunk costs to be added.

Cost of creating the new plan – These are labor costs and facility costs that would not be otherwise incurred. In some cases, these costs will be offset by iteration planning costs that would have been incurred using the initially chosen model.

Cost to execute the new plan – These costs will have to be compared to the cost of executing the original plan

Schedule

Most likely the time to re-plan the project will have to be added as will the time to execute the new plan as compared to the time to execute the original plan. If there are changes to the team composition, the availability of those new team members may adversely affect the new schedule.

Team Composition

The skill profile of the new team may be different from the skill level of the original team. Project team membership should be expected and the need for hand-off documentation identified.

Scope Change

There is still the possibility that scope change will affect the new plan going forward, but at least the deliverables and expected business value will have been defined.

Benefits

Following an agile or extreme methodology leaves open the final deliverables and the business value that will result. Following a traditional methodology removes those uncertainties and gives sponsors and executive management a criteria for portfolio decision making. That is more in their comfort zone.

Putting It All Together

This is not a definitive analysis because that is not possible without a specific project situation to consider. Rather, I hope I have defined the factors that must be considered when making a decision to change PMLC Models in mid-project. It is a complex decision with multiple criteria to consider. In my experience, the decisions have ranged from no-brainers to complex. There will be evidence supporting the change and evidence for no change. There will be intangibles too. For example, the team may have established momentum and what value do you place on that? The simple gut feel of the team may be the ultimate decision criteria.

Resilience – Thriving in Change

Written by George Pitagorsky on . Posted in Articles. 2 Comments on Resilience – Thriving in Change

Everything is subject to change. Nothing stays the same. To expect that it will is a delusion that leads to much suffering.

The ability to thrive in the face of change, particularly organizational change, and the uncertainty that comes with it, is critical to success in project management.

Managing Change

There are many types of projects across many organizations. The example here is one slice. The more you bring to mind your own situation, the more you will be able to see how you can improve the way you manage change.

Marv is the manager of a large process improvement program. Its goal is to improve the performance of an organization. He works with Jane, the senior executive responsible for the “target” organization. As the program began, Marv and Jane understood that they were going off into unchartered territory. No organization-wide major process change had been attempted for decades. They also understood that the current operation must continue uninterrupted and that substantial changes in policy, regulations, economic conditions, budgets can arise at any time to cause changes to their project’s goals and constraints.

They recognized the need to manage the change in business units and the need to manage changes at the program and project level.

Marv and Jane assessed the capacity of the people who would be implementing the process change and those who will be living with the results – several thousand people in line operations, middle management, project management and at executive levels. They concluded that a few key people were open to change and rational in their expectations. Many were “uncertainty averse.” They liked or needed things to be stable, definitive and predictable. Some had expectations of Nirvana by the target date of the program.

Change Management Strategy

A change management strategy was formulated:

  • Stakeholders would be eased into an acceptance of uncertainty and an understanding of their responsibility to adapt
  • Incremental planning and control would minimize the probability and impact of the disruptive change in operations using risk management, project control, pilot projects, focus groups, and incremental implementation. It would also set rational expectations about the outcome
  • Training, procedures development, and regular communication would give stakeholders a sense of what they can expect and what is expected of them
  • There would be transparency regarding changes and their impact
  • There would be recognition that the change, to be truly effective, would have to become institutionalized after several years of effort

The leadership team budgeted and planned for putting their change strategy into action. They made it an integral part of the program. Jasmine was assigned as Organizational Change Management Lead. Her role was to work with project managers, training, QA, communications, IT and others to create communication channels and content, discussion forums, training programs, procedures management, and the other components of a change management process.

Degree and Frequency of Change

Marv and Jane were wise to give change management the attention it deserves.

There are varying degrees and frequency of change in a project. Some changes are small or have been anticipated and have little impact. For example, a simple change in requirements. A few of these every so often are easy to manage. When allot of them come quickly, one after another, then things become more challenging. Other changes are more profound. They may cause you to radically change your plan or cancel the project. For example, major loss of budget, policy changes, changed key stakeholders, etc. When these are frequent, you are pretty much rudderless in the rapids of a fast-moving river.

In addition to changes that impact the project or program, there is organizational change, the change that impacts people when their roles, processes, values and environment change. Individuals have varying degrees of ability to accept and work with change.

As project managers, you are responsible for both keeping your boat, the project, afloat and minimizing undesirable change and disruption. To do this, you need resilience coupled with the leadership abilities required to keep all the stakeholders (including yourself) calm and able to respond rather than react.

How Do You Do That?

There is no simple answer, no off-the-shelf methodology or magical 10 step program you can follow. Though, there are capabilities, understandings, and guidelines that you can apply.

These begin with cognitive readiness and resilience.

“Cognitive readiness is the mental preparation (including skills, knowledge, abilities, motivations, and personal dispositions) an individual needs to establish and sustain competent performance in the complex and unpredictable environment of modern military [project/business] operations.” John E. Morrison J. D. Fletcher, INSTITUTE FOR DEFENSE ANALYSES (IDA), Paper P-3735 Cognitive Readiness, p ES-1]

Competent performance in the midst of change is resilience – able to adapt gracefully to change. It is a quality needed by any person or group “who must adapt quickly to rapidly emerging, unforeseen challenges.” 

Researchers have identified the capabilities that enable cognitive readiness and resilience. They boil down to:

  • a systems and process perspective to promote objectivity and awareness of the big picture and the details
  • the ability to manage emotions and work well with others
  • an open mind
  • the intention and capability to facilitate collaborative problem solving and decision making to drive appropriate situation action.

These capabilities are founded on mindful awareness.

As I point out in my new book, Managing Expectations, there is the possibility to set rational expectations in a planning process that includes the acceptance of uncertainty and change.

Putting these elements together we have guidelines for resiliently managing change:

  • Set rational expectations (especially the expectation that everything is subject to change) and manage them as the project unfolds.
  • Acknowledge that an effective plan with its tasks, schedules, resource assignments and budget, is subject to change
  • Manage the plan as the project unfolds – refine estimates based on a review of assumptions and actual results.
  • Continuously manage risk to identify, assess, plan for and control the change events that can be predicted and to remember that there are risks that will not be identified until they appear, usually at the most inconvenient time.
  • Communicate frequently to inform stakeholders about the organizational changes they can expect and how those changes will be facilitated.
  • Take a step back regularly to assess and report on how the project “looks and feels” – where you are, where you are likely to be going, the health of relationships, budget, etc.
  • Cultivate cognitive readiness and resilience in the entire organization through training and regular dialog that addresses process and systems thinking, attitudes, mindfulness, emotional issues, change management, problem-solving and decision-making process.
  • Have the courage to ‘let go’ of fear when you are faced with disruptive change so you can apply your skills, experience, and intelligence most effectively.

Utilizing Effective Communication to Affect Change – Lessons from the Field

Written by William Sheats on . Posted in Articles. 4 Comments on Utilizing Effective Communication to Affect Change – Lessons from the Field

Whether an organization is embarking upon an enterprise-wide restructuring or changing the flow of patients through a clinical area, the desired result is a change in the way in which work is accomplished.

Achieving this result requires the organization’s customers and staff to embrace and adopt the new ways associated with the change: create a shift in terms of the involved individuals’ behavior. Effective communication is a valuable tool in achieving the desired changes in an organization.

Effective communication throughout the lifecycle of the change initiative is required to enable and achieve a successful organizational change. Communication is the foundation for transferring the knowledge and creating the understanding associated with the specifics of the change. Our experience with a wide range of healthcare organizations indicates that when effective communication isn’t a part of a change initiative, success is difficult to achieve.

Whether on a personal or organizational level, change requires us to move from a relative homeostasis situation to one of chaos before returning to a ‘new’ state of homeostasis. Things may not look the same, the way in which we do things will change, and the environment in which we are now functioning may be different. One’s willingness and ability to accept and adapt to the change improves with an increased level of knowledge and understanding of the rationale for the change as well as the changes in behavior that are necessary to be successful. Effective communication is a powerful enabler to increasing individual knowledge and understanding.

Most successful organizational change initiatives embrace communication to accomplish several goals. The following represents the typical goals of our client base:

  1. Solicit input and feedback from a key constituency that engages them in the change;
  2. Review key aspects of the change and seek approval for next steps;
  3. Share information regarding the change, e.g., progress of the initiative;
  4. Recognize and ‘celebrate’ the initiative’s progress; and
  5. Transfer knowledge to the impacted constituencies of the change.

Most projects or change initiatives will want to develop and execute a communications approach to address all the goals identified above. The specific initiative will direct the scope and level of effort associated with each of the goals. For example, a hospital client that embarked upon a redesign of its clinics’ access process focused most of their communication efforts on the staff within the clinics impacted and their external patient population. Broad hospital organizational communication was limited to periodic progress reports to the senior leadership and recognizing the positive customer satisfaction scores resulting from the redesign. Within the clinics, all the goals were part of the project’s communication efforts. However, broader communication to the other hospital areas was not accomplished, creating confusion among the staff from these other areas when they interacted with the impacted clinics’ patients. Unfortunately, this resulted in the patients knowing more about the access process change than the employees of the hospital’s other departments.

This hospital client example is in contrast to the multi-provider healthcare system that simplified and standardized the process utilized to measure and monitor key patient quality indicators. The communication approach for this initiative embraced all five goals across multiple internal constituencies, including physician and hospital leadership, clinical providers, and patient quality staff. The result was a more comprehensive and faster adoption of the change across the organization.

One of the critical measures of success in implementing change is the degree to which the desired outcome of the initiative is achieved. Increases in staff productivity; reductions in the cycle times to treat patients; and increases in provider satisfaction are examples of planned change initiative outcomes. Achieving these outcomes require a change in the way in which business is conducted and the behavior of staff within the organization. The ability to affect this type of change requires the active engagement of all constituencies impacted by the change initiative, from the executive championing the change to the staff members who will change the way in which they interact with their key customer groups. Effective communication represents a significant enabler to a change initiative.

Our client experience has shown that organizations whose change initiatives embrace a communications effort are more than two times likely to achieve the initiative’s planned outcomes than those who didn’t approach their initiative with a comprehensive communications approach. Clients indicate that the process of communicating with key constituencies is the most important aspect of their efforts, as opposed to the specific means and content shared. Our experience is that simple, straightforward, well-written content produces the best results with constituencies. Elaborate, high-tech presentation methods tend to overshadow the basic content that the individuals need to embrace and adopt the change.

A second critical lesson learned has been the importance of using a variety of communication mechanisms, e.g., e-mails, physical signs or posters, frequently asked questions (FAQs), and face-to-face meetings. Constituencies respond differently to a variety of communication mechanisms, and even within a single constituency, our experience has shown it is more effective to vary the means in which content was shared. During the preparation of a tactical communication plan, ensure it represents a ‘mix it up’ in terms of the communication mechanism. During the plan’s development, solicit input from key constituencies or stakeholders regarding their preferred method of communication.

As a follow-up to this initial discussion with key stakeholders, periodically check-in with them to ensure that the content provided to them was understood in the manner desired. Communication requires more than ‘speaking and being heard’; it is about the listener understanding and comprehending the content provided to them. If it is determined that the communication efforts aren’t working, then adjust them to achieve the desired results.

It Never Hurts to “Know a Guy”

Written by Brad Egeland on . Posted in Articles. 5 Comments on It Never Hurts to “Know a Guy”

I’m sure you’re familiar with that funny phrase: “I know a guy” or “I have a guy for that.” Or even, “Let me hook you up with my guy.”

Well, the same goes for project management. Especially in technical project management. Asking for help and the expertise of someone outside of your organization is a way of life in project management. That’s why our teams, stakeholders, and other resources in the organization are valuable along with expert resources outside of our organization. Asking questions of all these groups of individuals and getting answers and information from them leads to making the best possible decisions and next steps for our customers and projects. This is especially true of the business analysts on projects. Why? Let’s examine these ideas and scenarios.

Seeking Technical Direction

In today’s complicated technology environments, it’s impossible to have a deep understanding of all things technical. The need for a Technical Expert for this happens on about every project. Why? Although the Business Analyst or Project Manager is strong in building relationships and eliciting requirements, they don’t have the in depth technical knowledge of a technical lead or application owner. Having the Business Analyst or Project Manager also perform the role of a Technical Lead is hopefully rare. Deep system and application knowledge can pull a Business Analyst or Project Manager away from building strong business relationships and eliciting fully complete business requirements. Going to more technical team members or even outside the organization for more savvy technical resources is a great idea when additional technical information is needed, answers are required fast and important business decisions are required.

Clarifying and Defining Project Requirements

There are going to be times when the project requirements need further defining. Perhaps even after they have been documented and work on the design or the development has started. It’s a natural occurrence and happens all the time – sometimes resulting in change orders. But it can’t be left to guess work – requirements must be clarified with the customer and possibly an outside expert technical resource when necessary. Failing to do so can result in costly re-work or an end solution that isn’t the right solution for the customer.

The Theory of Progressive Elaboration come into play here. At the beginning of the project you know very little about the details when formulating the project scope or design. As you progress or learn more about the details of the vision, goals, objectives and perhaps even the proposed solution your deeper understanding of the requirements. This typically results in scope or solution changes that are created by obtaining this deeper knowledge. Deeper knowledge also triggers level setting of project outcomes and expectations with project teams, stakeholders and project sponsors.

Getting Prices and Estimates for Change Orders

Another area where “knowing a guy” might be beneficial or even required is in the case of creating estimates and preparing change orders. We want our estimates to be accurate and we can’t always do that with the available team members, project manager or even others in the organization. An estimate may involve incorporating some yet to be used technology or service so knowing someone on the outside that possess that certain expertise could be a great benefit for getting an answer quickly and a change order proposal turned around to the project client in an impressive, accurate and swift manner. This all serves to help guarantee a satisfactory customer experience and a confident sign off on any needed change order work.

This is where Analogous estimating or estimating based on past experiences comes into play. Experts or other resources wither inside or outside the organization that have performed similar projects, will be able to provide a list of tasks or activities with durations. Duration of the task then drives the estimates. Care should be used with Analogous estimating techniques to ensure that tasks and durations would remain the same for the specific project. Validation of assumptions being made by external experts is critical to avoiding overly inflated estimates.

The Theory of Progressive Elaboration applies here. The estimates provided by outside experts are as good as their level of understanding for the project. The deeper the understanding of the project, the more accurate the Analogous estimate.

Experts at Requirements Meetings and Technical Discussions

Sometimes you need more than a phone call for some tough discussions. That’s when you might want to reach out to a “guy” or consultant who can come in, sit in on the business process discussions with the project client, sponsor or stakeholders to understand the “as is” and “to be” environment. Then help make some guidance decisions with those in the meeting. This consultant can be brought in as a subject matter expert (SME) to help guide the team to deeper understanding of the topic at hand or guide them down different path if the paths to create clarity. The result can be a solution that better fits the project and the real needs of the project customer and their organization.

It’s ok to reach out like this – it happens all the time. One thing that the Business Analyst and Project Manager will need to determine is if the solution is more technical or different than they understood it to be. Has the solution changed significantly due to our understanding? If not, they may need to eat the cost of this outside technical resource on their own in their own organization without the benefit of a change order to pay for it and a consultant or consulting organization like this won’t be cheap. But if the project is more detailed than the customer originally perceived then you can convince them that this resource is necessary to move the project forward and probably get them to sign off on a change order to cover this consulting service…or at least split the cost of it with your organization.

During issues or Testing or Break-Fix Work

Just like the requirements definition help mentioned above, there can be those times when you are testing a technical solution or trying to roll everything out and you can’t get past a few technical issues. It’s happened to me before. You may need to call in an outside expert to get the project past that performance testing issue or trouble spot. Again, you may have to assume all the expenses for this within the delivery organization without any change order benefit. At this stage, that is likely. But if you can justify it and feel ok about it, you can certainly try to get the customer to pay for part of it. It depends on the nature of the issues being encountered.

Summary

The key is to never hesitate to reach out for help. Never go it alone when you can seek help to get the best answers possible. The project’s success may depend on it so put the ego aside and bring in an expert whenever necessary. Anything less is not a smart move.

Readers – what are your thoughts on this? When you are lost do you stop to ask directions? Getting expert help can help you to stay clear of costly re-work that can wreak a project budget and timeline. Please share your thoughts and experiences below.