Tag: Change Management

Applying “A Sense of Urgency” to Project Management

Written by Kiron Bondale on November 11, 2014. Posted in Articles. 3 Comments on Applying “A Sense of Urgency” to Project Management

In his most well-known book, Leading Change, Dr. John Kotter presents an eight step model for transforming organizations with the first step requiring the establishment of a sense of urgency. Dr. Kotter expands his guidance for completing that first step in his follow-up book, A Sense of Urgency.

While Dr. Kotter’s premise is that companies and individuals need to develop and sustain a true sense of urgency to successfully survive today’s fast pace of change, his lessons also apply to project management.

This might seem like an odd topic to write about – project managers frequently feel over-pressured to deliver and that same pressure often translates to their team members. However, even on critical, high visibility projects, it can be difficult to sustain focused, productive true urgency.

Dr. Kotter states that the enemies of true urgency are complacency and a false sense of urgency.

Don’t these also apply to projects?

When you are leading a long duration project, it can be a common behavior for the team to develop tunnel-vision, focusing all their efforts on that next critical milestone. Through a combination of good team work, but also excessive heroics, that milestone is achieved. But what happens afterwards if the next milestone is more than a few weeks off? Does the team maintain their productivity at the same pace as their lead up to the milestone or do they breathe a sigh of relief and take their foot off the gas pedal? A sense of complacency has settled in. If you were to map the output level against time, you might see the build up to a milestone and then the drop off afterwards – success has become its own worst enemy.
While complacency is bad, a false sense of urgency is lethal. It can be easy to detect when productivity is slowing down and complacency has settled in, but it can be more difficult to identify when the frenetic pace of team member activity is not helping the project. Everyone seems to be really busy but is this true urgency? And if everyone is rushing around, harnessing and aligning their efforts to the right direction can take a lot of effort.

One way to test the waters is to find out if a team member knows what their top three activities are at the beginning of the day, and then assess at the end of the day how much progress they were able to achieve against those activities . If you find that more than a few of the team members, or even worse, you are unable to focus on progressing priorities in spite of a lot of effort being expended, the team is likely suffering from a false sense of urgency.

Sometimes this could result from poor risk or stakeholder management as both of these conditions can result in a backlog of challenging issues to resolve. Other times, it might be the inability of the project manager to effectively shield the team from sources of distraction such as frequent direct requests for project updates from different stakeholders.

So how do we prevent complacency or a false sense of urgency?

Dr. Kotter provides four tactics which should be used in conjunction. Each of these is applicable in the project management context.

Bring the outside in: This might be as simple as having the sponsor attend every second or third team meeting to recognize the team for their efforts, but to also reinforce the criticality of sustained effort. Depending on the nature of the project, if it is hard for the team members to envision the benefits which the project will deliver, it might be beneficial to bring in customers or stakeholders who are eagerly awaiting the completion of the project to provide their own encouragement and motivation.

Behave with urgency every day: This one is a bit trickier as it requires self-awareness. It can be so easy to fall into the habit of allowing decisions to be prolonged or accepting estimates at face value even when we know that they could be improved. When a team member says that a particular action can’t be completed by a given date, do we ask “What can I do to help improve on that?”. How often are we asking our team members what are their top three priorities and checking whether they have achieved those?

Find opportunity in crisis: One way to apply this tactic might be to help the team identify key lessons from a crisis and to use the heightened attention and support during the crisis as leverage to remove organization or process blockers. Dr. Kotter’s suggestion to selectively generate a crisis to overcome complacency and forge stronger team bonds could also be considered so long as that doesn’t blow up in the project manager’s face!

Deal with NoNos: NoNos are those people who effectively kill true urgency by either promoting complacency or encouraging a false sense of urgency. It might be the team member who is constantly distracting the rest of the team with perceived issues or the stakeholder who presents carefully selected data to support the assertion that there’s no harm if the project’s timeline slips. While you might not be able to directly push them out of your organization, actively distracting them if they are not on your team or exposing their behavior such that the social forces within the team cause them to reduce or stop it may work well.

On a long running project, a true sense of urgency can ensure that early successes aren’t eclipsed by late inning failures. Team members and stakeholders then take what they learned from that one project being led with a true sense of urgency and apply that to their next project.

And that is how successful organization culture change happens.

Don’t forget to leave your comments below.

From the Sponsor’s Desk – Beware the Change within a Change

Written by Drew Davison on October 28, 2014. Posted in Articles. 3 Comments on From the Sponsor’s Desk – Beware the Change within a Change

In my last post, A Moment of Truth, we looked at a chance personal encounter – a moment of truth – that changed the lives of two people for the better. The post wasn’t about a project, or a major change. It was about how individuals react when faced with change. Sometimes, as in this case, all we need to move forward is the help and support from another person, to offer a different frame of reference for our consideration.

In this post, we’ll review the damage done when one organization didn’t pay sufficient attention to a change within a change. It’s easy to get distracted when dealing with a major project, like an acquisition. But, as we’ll see, being busy with a big change is no excuse for ignoring other significant changes that are going on concurrently. Appropriate oversight and diligence is always needed.

Thanks to A.T.P. for the details on this story.

The Situation

This bank purchased an investment organization that ran into difficulties as a result of the 2008 financial crisis. As the bank was dealing with the integration of the acquired company, they discovered that the investment organization had undertaken and were in the midst of a major upgrade to their core administrative system involving the software’s vendor and a sizeable in house team.

The bank inherited the $3 million contract with the vendor negotiated by the investment company. The original plan was to have the software upgrades completed and installed by the time the acquisition was finalized. That hadn’t happened. The price was based on specifications provided by the vendor detailing the changes that would be made to the application. Most of the $3 million had been spent at the time of the acquisition. It was estimated by the previous project leader that another $1 million in vendor charges would be needed to complete the upgrade.

As a result of the acquisition, the bank found it had excess management including the former Director of Operations from the investment organization. So, they assigned him to run the software upgrade as the project director and redeployed the previous project manager to another part of the overall acquisition project.

The Goal

With so much change going on as a result of the acquisition, the bank decided to let the software upgrade proceed as planned under the guidance of the new project director. The target budget for vendor expenses was $4.2 million. The project was planned for completion in ten months.

The Project

As the project progressed and the project director started to get acclimatised to his new role, a number of concerns began to surface:

Apparently, the software vendor wanted to exit the market for the particular product being used by the investment company. It was doing the project under some duress and with the benefit of a sizable bonus above and beyond the actual project costs.
The vendor had pulled key resource off the project in the past and continued to do so. That was a major contributing factor to the cost overruns and extended schedule.
The bank’s quality assurance staff found that the specs didn’t provide the necessary insight to support testing to confirm the software addressed the company’s needs.
When the director starting chatting with the business executives about their goals for the project and their operational requirements and priorities, he uncovered a quagmire. The executives had different views on why the project was launched, what the benefits were, what organizations were affected and how much.

What seemed like a reasonably safe and routine project was turning out to be anything but. The project director assigned a team of analysts to work with the business units affected to go back to basics, get agreement on the opportunities being targeted, the projects goals, benefits, priorities and flesh out the specifications so the testing could be carried out expeditiously. Now that the business units were being engaged, the business heads started demanding significant changes in the software beyond what had already been delivered.

The project director started negotiations with the vendor to add the additional functionality and ran into road block after road block. Their quotes to include the additional functionality were excessive (an additional $2.5 million), the time frame unacceptable (two additional years). He wanted them to leave current staff on the project and bring back some key resources that had been reassigned. They refused. The vendor made it perfectly clear that they had no interest in expanding the project beyond the original scope.

The Results

Fourteen months after the decision was made to continue the project, and four months after the revised completion date, having paid the vendor $4.6 million plus the bonus, the project director recommended pulling the plug on the project. His exit strategy included:

Negotiating the purchase of the source code from the vendor, including the current production version and the development version with all applied changes to date.
Completing the project with in house resource only after a rigorous priority setting process to ensure real value from the investment.
Development of a phasing and staging strategy to accelerate benefit delivery and reduce risks.

The project director was able to negotiate a non-exclusive purchase of the code and related utilities and documentation for $425,000. He was also able to hire three key staff from the vendor who had years of experience with the system. With the help of senior business managers he was able to prioritize and value the remaining work and package it into three distinct releases. The final release was implemented a year after parting ways with the vendor at an internal cost of $900,000.

How a Great Leader Could Have Changed the Outcome

Isn’t hindsight wonderful! We now know that this project was in trouble when the bank took over the investment company. It was still in trouble when the bank made the decision to let the project run its course. This $3 million project that was to be completed prior to the acquisition actually cost over $6 million and finished over two years late.

The steps the project director eventually took to reign in the runaway project were the right ones. Unfortunately, he waited too long to get up to speed. What could he have done differently?

He sought to get the vendor on side and ultimately realized the vendor had other priorities and wasn’t interested in the market, the software or the project. The vendor had been saying all along that it would not continue to support the software. Why then did the investment company decide to proceed? Why did the project director pursue the purchase of the source code as his only option? Both occasions were perfect opportunities to look at other alternatives that would offer long term value including other vendors and other platform offerings.
He got the key business decision makers together to make the call on priority, value and packaging. Unfortunately, that should have happened as soon as he took over the project director role. He would have discovered that they had not been actively involved, didn’t have a consensus on what they were trying to achieve, didn’t know how well the revised software would satisfy their needs and hadn’t participated in any implementation planning or priority setting.

There is some key knowledge that is required about every project by all key stakeholders. If it’s not captured up front, invariably it will create difficulties later on. To remedy those problems, the missing knowledge will have to be acquired and revisions will have to be made in light of that knowledge, costing time and money. In this case, that’s exactly what happened. It seems everyone was too preoccupied with the big change, the acquisition, to spend quality time and effort on a smaller but still substantial project.

So, whether you’re starting out on a new project or getting involved at some later point, whether you’re looking after a smaller part of a bigger change, do a checkpoint. Make sure that essential knowledge is available and assimilated by the key decision makers. That includes the following:

The framework above includes a portion of the full Project Pre-Check Decision Framework.

So, if you find yourself in a similar situation, don’t hesitate to do a checkpoint. Check that the essential knowledge is available and agreed to by all the key decision-makers. Finally, put these points on your checklist of things to do in future endeavours so you too can be a Great Leader. And remember to use Project Pre-Check’s three building blocks right up front so you don’t overlook those key success factors.

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 present it for others to learn from and comment on.
Thanks

Don’t forget to leave your comments below.

Say What You Think to Promote Project Success

Written by George Pitagorsky on October 21, 2014. Posted in Articles. 7 Comments on Say What You Think to Promote Project Success

Not speaking up about controversial issues can cause project failure.

It takes courage to speak up in the face of a perceived flaw or error. This is particularly true when the idea being critiqued has been put forward by someone in a hierarchy above you. First, you might be wrong. Then again you might be right and subject to firing or other penalties. Courage is not enough, though. Timing and diplomacy are also required. It is all about saying the right things at the right time to the right people in the right way.

The Trip to Abilene

The Trip to Abilene is a story by Jerry B. Harvey about how four intelligent and well meaning people took an unpleasant trip to somewhere that none of them wanted to go. The Abilene paradox is a phenomena that takes its name from this anecdote.

The Abilene paradox is the cause of many a misstep by organizations. People do not speak their mind when what is in their mind is opposed to the perceived general opinion of the people around them. Note that the Abilene paradox is different from group think. With group think, people are convinced that the group’s idea is sound. In the paradox, people are consciously aware that they oppose the idea and are acting contrary to their own thoughts and insights.

People don’t speak up because they may think that what they have to say is unimportant, possibly stupid, and/or bound to upset someone. They may fear retribution and censure. Sometimes this fear is quite rational. There are many examples of whistle blowers being persecuted. Many examples of the negative effects of arguing against the favored idea, design, plan, etc. Further, it takes effort to come to the table with a compelling argument. Harvey, quoted Herbert porter a Nixon campaign aid as saying that he “was not one to stand up in a meeting and say that this should be stopped”, a decision he then attributed to “the fear of the group pressure that would ensue, of not being a team player.” Porter was referring to the Watergate scandal.

Few will risk saying that the emperor is not wearing any clothes. Hans Christian Anderson’s tale of the Emperor’s New Clothes is another way of bringing out the difficulty of saying what you think. In this story, a vain emperor is tricked into believing that he was getting a suit of clothes that could only be seen by the most intelligent people. No one but a child had the courage to appear unintelligent and tell the Emperor that he wasn’t wearing any clothes. The emperor himself was too vain to admit that even he couldn’t see the new suit.

Whatever the reason, not speaking up is a problem.

Example

For example, in one project to implement cultural and technological change in a large organization, the project sponsor had in mind aggressive objectives coupled with an aggressive time line and a limited budget. When he stated his desires to his direct reports some of them thought the objectives were great while others hated them. No one argued. Some thought “nothing I could say is going to change the situation so why bother.” Others thought “the change is going to fail, all I have to do is wait.” Still others thought “I don’t want to be seen as a naysayer.”

With tacit consensus on the idea, the next step was to define the approach. How would the project achieve the change within the time frame and budget? Here experts were called in to design and estimate the various parts of the project. Some came back to their managers with the bad news that it was impossible to hit their targets and therefor the overall target could not be met. Whether Driven by the desire to meet the target date or the fear to tell the sponsor that the target date was not viable, the middle managers pushed their experts to make it work.

It is easy to make a complex project work on paper. The realm of planning is conceptual. A complex environment is simulated and, for the most part, over simplified. Planners and estimators can adjust the plan to fit any target date and budget. This may be done intentionally to sell some services or meet an imposed demand from above. Alternatively, It may happen inadvertently because the planners are too optimistic and they don’t adequately manage risk.

Based on an overly aggressive, unrealistic plan the project was approved and kicked off. Expectations were set in the minds of the sponsors and other stakeholders. Off the organization went on a trip to Abilene.
Once the work started and people began to interact, the real world of complexity, ambiguity, resistance and poor communication came into view. To compound the problem, status and progress reports were influenced by fear and the Abilene paradox continued to manifest itself in the area of project reporting and control.

Open Discussion At the Right Time

If one of the many people who knew that there were good reasons to not go on the trip had spoken up and put forward his/her reasoning the others may have listened, thought about the ideas, had a discussion about differences of opinion, risks, rewards, etc. and then made up their minds. The outcome can be far better when there is open discussion.

Doing this at the right time in the life of a project is important. Open discussion requires that people speak their mind in a constructive attempt to reach mutual understanding and agreement. When initiating, and planning a project it is best practice to establish a formal process to cut through the causes of people holding back. Open discussion generally means not only being open to conflicting ideas but to actually promoting conflicts by requiring that alternative ideas are raised even when it seems as if everyone is behind the idea that is on the table. Risk assessment is an example of how a team can create the space and give people permission to “be negative”. It motivates people to bring up issues that in the absence of the risk assessment context would make them seem like they not are being team players. By making risk assessment part of planning as well as part of any major decision there is a greater likelihood that open discussion will take place at the right time.

Sometimes we find that people speak out after what they have to say can no longer be acted upon. Instead of arguing about the details of requirements when the product is delivered, discuss or even argue about them when the requirements are being defined. A statement like “I could have told you so” is a sign of dysfunction. If you think something is wrong, say so.

Diplomacy

Diplomacy is artfully dealing with people with sensitivity while being effective. It is knowing the right way to say the right thing in a situation. Diplomacy is necessary as a balance for the assertiveness that is required to be candid. It can be taken too far and then be used as a way to avoid saying anything that might be disturbing to anyone. But in the right measure it is an important skill. It enables a person to say something that is controversial in a way that is least likely to arouse hostility while promoting healthy conflict.

Conclusion

The bottom line is that unless people say what they think at the right time and in the right way about key issues, projects and processes in general are more likely to fail. Commit to being candid and to taking the risk to say something you think will make you unpopular. If you can, make it as easy as possible for others to say what they think.

Don’t forget to leave your comments below.

Uncommon Common Sense Project Management

Written by Lisa Anderson on October 14, 2014. Posted in Articles. 8 Comments on Uncommon Common Sense Project Management

Why is everyone searching for the latest and greatest technology and fad when common sense will drive bottom line business results? It seems that it is an exciting conversation piece to talk about potentially intriguing technology or concepts such as agile, and so we all get caught up in it. However, when I look across the hundreds of projects implemented by my clients, the key to success boils down to uncommon common sense.

For example, one of my large manufacturing clients is running multiple projects simultaneously. They have been using lean techniques and bringing in consultants who are gurus in utilizing the latest technologies and processes. Of course, none of this is “bad” as results will occur; however, it doesn’t have the same impact as utilizing uncommon common sense.

In one area, there is an overload of work on specific machines which they can see by looking at the visual signals on the plant floor. If you go to the production board, you can see immediately which items and machines are overloaded because they are highlighted and obviously overflowing. After sifting through loads of system data to review the problem through the best and brightest analytical formulas, it was determined that a select few products were best to move to a new production area for focus on improving output.

Not surprisingly, output increased for those items! However, the items were moved to machines which were already overloaded and overflowing, and so although output increased, the already overloaded items were deprioritized for the select few products and past due temporarily increased. Uncommon common sense would say to review the production board which clearly showed this problem or ask the planner to avoid this significant roadblock on the path to success. It seems obvious in hindsight yet wasn’t obvious to the team in the situation – a perfect example of why common sense is not common!

If we can leverage uncommon common sense, it is likely we’ll surpass our competition. Thus, what do we need to do in order to utilize uncommon common sense? 1) Go back to basics. 2) Ask your team. 3) Think before leaping.

Go back to the basics: A common theme for those clients who consistently perform at a higher level than the rest is a respect for the basics. Do you value the basics? If you don’t show it, your team will never focus on them. You get what you value and measure.
In project management, the basics include understanding the objectives of your project (which can sometimes come in the form of a project charter), developing a project plan with cross-functional teams as appropriate, soliciting feedback and being willing to address potential roadblocks, and managing the critical path. It is far from complex; however, it is rarely executed. Make sure you do not divert from the basics.
Ask your team: There is nothing more important than involving your project team in the compete process. Make sure they understand the value. Asking the right questions will lead them to this conclusion. Ask for input. Never ask and then beat a project team member up for alerting you to problems and roadblocks. It is almost as bad to ask and ignore. Make sure you request input, value the input and get back to them with whether it will be incorporated and why or why not. Simple common sense courtesy goes a long way to encouraging million dollar ideas which can be easily lost in the shuffle.
Think before leaping: One of the keys to success in leveraging uncommon common sense is to take a step back from the daily grind. Remember what is to be accomplished. Think about the options for getting there. Identify the most direct path to success. As Occam’s razor says, the simplest path is often the best one. The bottom line is to think before leaping.
Certainly uncommon common sense will also tell you to not do this alone. Bring your best and brightest together, provide the vision and involve them in the process. Make each person accountable for holding the other team members accountable for thinking of the simplest path to achievable the result before pursuing any path. It will seem radical at first; however, if you stick to it, results will follow.

In today’s new normal business environment, project results are of paramount importance as growth and profitability is cornerstone to success. Why not try uncommon common sense to not only simplify your project team’s lives but also to guarantee success. It boils down to becoming ultra-clear on the objectives, taking the step back and setting aside the appropriate time to determine how to simplify the project plan and path forward to only what is essential to success. Rapid progress and an acceleration of results will be your reward.

Don’t forget to leave your comments below.

Reducing Time to Market Can’t Come at the Cost of Sustainability!

Written by Kiron Bondale on September 30, 2014. Posted in Articles. 2 Comments on Reducing Time to Market Can’t Come at the Cost of Sustainability!

Time to market has become a key metric for measuring the successful delivery of both product/service development and internal projects. Reducing it has been the focus of process improvement initiatives and modified project lifecycle approaches and has been one of the contributing factors to the significant increase in interest in agile methods.

Intuitively, it should make sense that companies would want their projects to be completed in a shorter amount of time. Doing so would offer a number of advantages including first to market competitive advantage, being able to implement operational improvements faster or reducing business risk by complying with regulations ahead of deadlines. Beyond this, the opportunity cost of tying up skilled project resources for longer than is absolutely necessary is reduced and it should be possible to complete more value add projects over the same duration.

As with all metrics, to truly exploit the benefits of time to market, it is important to measure it in a way which will meet expected outcomes while reducing unintended consequences. The classic example of time reduction done wrong is the call center which measures and provides performance incentives to customer service agents based on how quickly they answer and close customer inquiries. Over a fairly short period of time, average call duration is likely to fall, but so will customer satisfaction.

In the context of project management, the same holds true.

For sponsors or stakeholders who might be frustrated with how long it takes project teams to start delivering scope against approved baselines, one way to address this might be to shorten the time from project kickoff to development & signoff on baselines.

Unfortunately, the unintended consequences of this might be that insufficient planning takes place or an appropriate level of stakeholder engagement is not achieved. In both cases, stakeholder dissatisfaction and increased numbers of project issues and change requests arising from missed requirements are likely to be the outcomes. You might argue that an agile project lifecycle would avoid this situation, but even with such projects, cutting corners by reducing effort spent on key architecture or design work in early sprints will result in waste in later sprints.

Sometimes the request from stakeholders is not to focus on reducing the time to complete planning, but rather to shorten overall duration before the very first deliverable is implemented. This is a reasonable expectation – projects are investments, and the longer the customer has to wait to realize the expected outcomes, the greater the likelihood that external influences will reduce benefits.

One of the more common unintended consequences of a push to reduce change delivery duration is reduced deliverable quality. As we know, increased defects results in a higher cost of quality including waste, damaged relationships with suppliers and customers, reputational damage and an increased likelihood of legal action against the company. Worse yet, such a focus can have long term behavioral impacts on the organization – once staff learn that leadership emphasis is on the speed of delivery instead of how those results were produced, it can be extremely difficult to re-instill a culture of quality.

But let’s say that deliverables are still being produced with acceptable levels of quality – should we claim mission accomplished?

In such cases, change sustainability might be the Achilles heel of the reducing time to market movement. Just because project deliverables have been implemented, doesn’t mean that desired change outcomes have been realized.
When corners are cut in analyzing change impacts on stakeholder communities, preparing these stakeholder communities for the change, progressively communicating to affected stakeholders, cultivating change champions and advocates, and using high touch approaches of overcoming short term resistance and soliciting feedback, expected behavior changes are likely to be short-lived.

This impacts not only the successful realization of a given project’s benefits but will result in a corresponding increase in the levels of change stress in affected stakeholders which in turn will cause reduced resilience and appetite for further changes.

So how can the unintended consequences resulting from a focus on reducing time to market be avoided?

The key is to design a performance evaluation model which utilizes a holistic approach to measuring project success. While time to market, or cost of delivery are important, there also needs to be post-project metrics focusing on the volume of defects, quantifying the degree of compliance with expected behaviors, measuring stakeholder satisfaction, and evaluating overall benefits realized.

You can only manage what you measure, but if you short-change what you decide to measure, you will get what you paid for!

Don’t forget to leave your comments below.