Skip to main content

Tag: Change Management

Change Management to Move Projects Forward

Written by Joan Demuth on . Posted in Articles. 6 Comments on Change Management to Move Projects Forward

Change Management is Misunderstood

“The only man I know who behaves sensibly is my tailor; he takes my measurements anew each time he sees me.  The rest go on with their old measurements and expect me to fit them.”  ~George Bernard Shaw

There is a misconception, in many organizations, that if we simply keep moving along with the changes, without officially acknowledging or evaluating their impact, that everything will work out in the end. People with this naïve approach believe:

  • The project will be within the budget.
  • The end product will ultimately be better and support our project Return On Investment (ROI) and strategic value.
  • The cost and timeline will still be met.
  • No one is worse for wear.

This misconception is especially strong when small to medium-size projects are deployed. After all, we have done this successfully in the past without the ‘formality’ of change management.

The reality is, change absolutely causes dysfunction within a project team. When change is introduced and not communicated properly it leads to:

  • Confusion and frustration of what is required, infiltrating components of the team.
  • Some members of the team not knowing a change was introduced and they do not perform tasks to support that change.
  • If tasks are not performed to support the change, additional time to correct this is required during development, testing and training.
  • Delays are often experienced or unnecessary overtime.
  • The change that was introduced, informally, may be retracted; causing some work to be ‘backed out’.  This assumes there is a formal declaration the change was rejected; which of course there probably isn’t. The team just knows.
  • Stakeholders may think the requirements are different than they are.
  • There is no history of the changes to help ‘tell the story’ of the project.
  • Change in direction could affect the overall business alignment, vision and training; without those areas realizing the change took place until it’s too late to correct.

Agree on Changes that Add Value

“All change is not growth, as all movement is not forward.”  ~Ellen Glasgow

I was recently on a project where many changes were introduced, after requirements were agreed upon and ‘finalized’. Many of these changes made good business sense and we understood the need to the end user. However, the customer was tasked with remaining on-time and staying within budget.  How can significant change keep us on-track and deliver on-time and on-budget?

Here is some background: Our customer needed to produce a sales scorecard for our field representatives. Key metrics were essential to help managers coach and mentor the sales staff. The reporting scorecard, with drill down reporting capability, would be the tool to help them understand the weekly sales and be the driver to help the business meet plan. If we didn’t deliver in a timely manner, the field might not have time to react and meet projections.

Therefore, the Project Manger (PM), Business Analyst (BA), customer and project team agreed that before the team worked on any changes in direction or ‘new’ requirements; the change would be evaluated and presented to our customer. We put into place a controlled change management process as follows:

Impact of the Change

In order to understand the impact of the change and provide an accurate evaluation, the Information Technology (IT) team may need five minutes or up to a couple of days. Many times the IT team needs to determine if the request can be supported with data, configuration or code changes that we already have, or if a new process needs to be developed. The business too may need to spend time determining impact to the field, training and/or ROI.

In my project, the PM and customer would discuss the amount of time and impact it would take to evaluate the change, prior to putting rigor around gathering information on the impact of the change itself. In some cases, the fact the change would take 15 hours of work to determine impacts to cost, timeline and resources while also delaying the release by a day; was enough to cancel the change on the spot with no additional effort. The PM would document this in a Change Log, being sure to document the decision, but would not create a formal Change Request Form. This was a quick and easy way to weed out ‘nice to haves’ or changes that didn’t really move the business forward.

If the time to evaluate the change and associated impact was accepted, the core team would be assembled for evaluation. The following questions would influence the team’s  go-forward plans:

  1. Do we understand the new request? If not, we would get more clarity from the customer.
  2. What tasks would need to be added to our work to accomplish the request, including requirement gathering, changes to design, additional testing, new process development, configuration changes, training and so on?
  3. Do we have the resources to fulfill the request and if not, who do we need?
  4. Impact to timeline, if any?
  5. Impact to cost, if any?
  6. Are there any risks introduced? What are they?
  7. What are the benefits to fulfilling the request, from the business and IT perspective?
  8. Do we have any options for the business in order to accomplish the goal but at a lower cost or timeline for delivery?

Since time was of the essence; we would do this quickly after the change was recognized.

During this evaluation, work continued as originally planned. No one on the team would begin work on the change. The work did not begin on the change request until the customer accepted the cost, timeline and solution impacts.

Communicate the Change

The PM would communicate the results of the evaluation to the customer within a couple of days, max.

Our customer was then armed with all the information they needed to determine if the impact of the change was acceptable or determine if the impact was too large and if the change needed to be rejected.  

Once the customer approved or rejected the change request, the PM would send a message to the entire project team providing the status. If the change was accepted, the team changed direction and followed the plan to work on the items needed to support the change. If it was rejected, the team was aware and simply continued work as originally planned.

Benefits of Change Management Process

The benefits of this process for our team included:

  • Allowing the business customer to have all the facts in front of them before deciding to move forward.
  • Customer understood why a request, that sounds small from a business perspective, could be significant on the IT side.
  1. Using change management and the evaluation process, the customer could be educated on all impacts to the relatively simple change request.
  2. For example:

We would like to know the sales by x, y and z. However, IT found out that x, y and z were not captured at the point of sale and not stored on the database. The IT team would need to apply complicated business logic to the data in order to derive it. This meant complicated test scripts and data validation efforts. All of this added considerable time to what sounded like a simple piece of data. The business customer didn’t like the fact the information needed to be derived in such a complicated solution, due to past training issues on ‘where did this data come from’. The customer opted to reject the request. The customer was armed with new information and elected to create a project request to capture the desired information at the time of sale.

  • Saves time and ensures on-time delivery because ‘small’ unexpected changes popping up mid-stream are not allowed to divert efforts, unexpectedly adding significant amounts of time, risk or large issues to the project.
  • The customer, project team and other stakeholders were always kept abreast of the status of any change requests and were not blindsided by changes they were not aware of.

Ease into the Change Process

“If you want to make enemies, try to change something.”  ~Woodrow Wilson

Some ways to help the project team understand that proper change management will ensure quality, keep us on task, maintain the timeline and help us focus on the high priority change that leads to growth are highlighted below:

  • Support the idea of accepting new changes from the customer on a regular basis.
  1. Don’t treat change as a roadblock; treat it as an opportunity to improve the product.
  2. Pass the positive attitude on.
  3. Help your team understand you are committed to saving them time and money, as well as producing a quality product.
  4. If the timeline needs to be extended, you support that too!
  • Initiate the change management process in its most simple format.
  1. Use the change log. Create a quick and dirty excel spreadsheet. Have columns for the Change Reference #, Description, Status, Cost Impact, Time Impact, Decision, Approver (who can also reject the item) and Notes.
  2. Track all changes in the change log and use this for communication.
  3. As your organization matures, it will be easy to introduce a Change Request form that has more details.
  • Bring forth options.
  1. When IT understands the reason for the change, IT should be able to produce several solutions that would result in the same benefit.
  2. Options bring with them choices, choices lead to better decisions.
  • Appoint a change board.
  1. Identify the person, or group of people who will come together to discuss the impact of proposed changes and approve or reject them.
  2. This group will quickly see the value in evaluating the true business benefit and need when they factor in all the impact the change will create.
  • Follow through!
  1. Don’t let the process slip.
  2. Act quickly when a change is proposed.
  • IT must recognize, evaluate and bring forth options in a timely manner. The longer you wait, the more impact there will be.
  1. Communicate results to all team members and stakeholders.
  • Everyone must understand the decision and impact so they can react.

The Joy of Change

“Nobody can go back and start a new beginning, but anyone can start today and make a new ending.”  Maria Robinson

After initiating it, my customer was completely sold on the change management process.

We did initiate change along the way, utilizing change management, and we knew what we were dealing with and understood all related impact.

As change requests were approved, hours increased, our date moved out and training was adjusted to meet the needs. The entire team was communicated with and knew when a change in focus was initiated and agreement gained.

The delivery was on-time, within the approved budget and met all expectations

Since we used this process, the entire team from analysis, design, development, configuration, testing and training efforts could support and execute against agreed upon scope changes. There was very little post-implementation support, because we captured all the requirements and planned for all scope changes along the way.

So, even though the project evolved from the ‘original’ plan, it was a controlled, well-planned and executed change. All business and IT folks were informed. The end product was quality that drove the business forward. That’s what it is all about!

Don’t forget to leave your comments below.

Joan Demuth, PMP, is a Project Manager with Bremer Bank. Before joining Bremer, she led continuous improvement initiatives as well as served as the lead senior project manager on multi-million dollar IT projects. Joan previously served as a Business Analyst for more than 7 years. Joan has an MBA from the University of Sioux Falls.

The views in this article are solely the views of the author and do not reflect the views of Bremer Bank or its affiliates.

Has The Economy Changed How We Do Projects Forever?

Written by Jim Hannon on . Posted in Articles. 8 Comments on Has The Economy Changed How We Do Projects Forever?

Sept7FEATUREIn the continuing drumbeat of bad economic news over the past month, there is a fundamental underlying shift on how this economy has impacted project selection and execution. This is also an excellent opportunity for the creative risk-taking PM to gain a career advantage and strengthen the role of the PMO in today’s companies.

Trend Number One: Companies want to do more with less

We have all seen this trend and unfortunately some of us may be among the casualties of this trend. I advocate that Project Management is more important than ever to fully understand how we do the basic package of work in business: the project. I want to be clear in this area: the PM must be a hands-on PM not an administrator. The company needs to have a cost and

efficiency watchdog in the project and the PM should take on this role. In the majority of companies, the first question a new PM should ask is, “How many projects do we have ongoing?” I guarantee the answer is usually, “No idea!” I always find it amazing a company will spend the treasure of the company and have no idea what they are spending it on, but always think PMs are too costly! The PMO should also be at the vanguard in advocating the proper allocation of resources and ensure that a constant return is being delivered in each project

Trend Number Two: Trust has gone out the window

In today’s project, the team constantly hears of layoffs and constantly lives with the thought, Am I next, no matter how talented you are in your job. This trend may be very pronounced in your company or it is lurking under the surface and senior management does not want to acknowledge the issue. This trend is probably the most troubling today and will have a long-lasting impact. The members of your team may believe that creativity and thinking outside of the box is too risky and will open you to being on the layoff list. The team may also believe that they should not help other members of the team, and worse they believe that making the other person look bad is the best offense and takes the harsh light off them and their tasks. The PM must address this head on with the appropriate managers and get a solid buy-in from them as these petty issues will not be tolerated in the project. The PM along with the managers needs to then deliver that message to the team and all be held accountable if issues arise. The key here to remember is that TRUST=PRODUCTIVITY.

Trend Number Three: Give the customer their money’s worth

In many projects over the years, we all had the proverbial “day two“ list. In the new economy, the customer not only requests but demands their money’s worth. I am not advocating you throw to the side the idea of scope creep, but why would you now need to set a clear standard that a small change you classified as day two before needs to be completed to ensure the future revenue stream with the client. The PM must ensure the deliverables are fully documented and the communication is solid from all ends of the project so expectations are clearly set on what is being produced and when… 

Trend Number Four: Will companies ever undertake a large project again?

We have all been involved in the large mega project and wondered quietly, How can this ever be done on time, within budget? I am a practicing PM and I sometimes question the project fundamentals of these projects so a senior manager who is not a project person has even more doubts. I believe mega projects will not go away but funding will be more difficult, and PMs will be held to a much higher level of responsibility and be measured on the triple constraint. I also believe that as PMs, we need to advocate for strict approaches where we do wave planning and break projects into smaller components. I fully recognize the need for an agile approach, but please do not be enamored by phrases. The bottom line is you have to do the work the most efficient way possible.

I realize there are other trends but this article is meant to stress that in a down economy, strong Project Management is even more crucial to the execution of the company’s business strategy.

Don’t forget to leave your comments below.

Jim Hannon has over fifteen years of diversified experience in the Information Technology and Financial Services Industries, functioning primarily as a Senior Project Manager/Lead Business Analyst/Program Manager with proven experience in trading systems and numerous financial applications domestically and global. Jim currently holds his MBA, PMP, PM-RMP and is certified in Prince 2 fundamentals. Jim is planning on sitting for the PgMP and PM-SP in the next 6 months.  Jim also teaches Project Management at Boston University and Excelsior College and created the PM program at Excelsior. Jim is also a Senior Professor at Cambridge College. Jim works for a major IT firm and also has a consulting firm The Bentley Group, which offers PM and Business Analysis services.

Project Management – Why “Good Enough” is Often Enough

Written by Mike Morton on . Posted in Articles. 2 Comments on Project Management – Why “Good Enough” is Often Enough

FeatureAug17thIt’s a phenomenon that I’ve witnessed sufficiently often that the evidence can no longer be termed “anecdotal”.  An organization wishes to improve their project management capabilities – through investments in process, staffing and/or technology they experience some initial successes.  But a few months in to the initiative, momentum and enthusiasm wane and focus shifts resulting in the capability improvement hitting a plateau or even worse back sliding to pre-improvement performance.

There are multiple triggers for this behavior, some of which I’ve covered in previous articles:

  • Lack of effective, committed sponsorship
  • Improvement initiative was not structured, planned or managed like a project
  • Lack of a multi-phase roadmap with SMART business objectives defined for each phase
  • Ineffective change management
  • Shifting priorities cannibalizing resources from improvement efforts

There’s an old saying “Anything worth doing is worth doing well”.  I’ve underlined the initial use of worth because it identifies a probable root cause – project management is considered a hygiene factor by many organizations as opposed to being the source of competitive advantage that associations like PMI have attempted to evangelize. 

For a typical organization, once critical project management issues have been addressed, the change effort involved to achieve a higher level of maturity can’t be justified and focus shifts to other priorities.  Hiring skilled project managers is often viewed as a simpler approach to addressing project predictability challenges.

This behavior tends to be common in industries where competitive pressures are low, service and product prices are high, or they have a captive market.  For example, a few years ago in the legal industry it was difficult to gain buy-in for capability improvement initiatives because most law firms were doing very well in spite of having low project management maturity levels. 

An analogy can be drawn to IT operations management – while there is significant knowledge about methodologies and best practices, most organizations are still choosing to operate at a low level of maturity.

Does this mean you shouldn’t try to champion or launch a PM capability improvement initiative?  No, but you should be realistic about expected outcomes, and focus on developing and implementing changes that will fit the culture of your organization.  “World class” project management capabilities do not make sense for all organizations.  As with any capability improvement initiative, it is crucial to balance the hard and soft costs against expected benefits when defining a target for improvement. 

Avoid gold plating – each change should have a demonstrable connection to a perceived business benefit.  The “engine” of improvement initiatives runs on the “fuel” of success so make sure to track and report all achievements.  And keep “soft-selling” the value of project management.  With persistence, planning and realistic expectations, managing your capability improvement initiative will not feel like a roller coaster ride!

Don’t forget to leave your comments below.

Don’t Let Your Project Take a Hit, Control Change!

Written by Brenda Hallman on . Posted in Articles. 3 Comments on Don’t Let Your Project Take a Hit, Control Change!

Fotolia_10510675_XSFor a project manager overseeing changes it’s like playing an old arcade game of asteroids.  You have the control; but rather than protecting the Earth from approaching extraterrestrial rocks you are protecting your project from changes that could result in delays, confusion, missed deliverables and inaccurate expectations.  While project changes will not be devastating to the planet, they can be to your project if not properly managed.

Changes to a project may be in the form of new or changed requirements, the result of an issue, new information which has unfolded, resource constraints, or shifting priorities of the organization or your project leaders.  As a project manager you must accept this and realize that controlling changes and protecting your project are a primary responsibly toward the monitoring and controlling of your project.

During the monitor and control process, the project manager is observing project execution to assure that potential problems are identified in a timely manner and corrective actions are taken to keep the project on track.  This includes the monitoring of ongoing activities to assure that changes are controlled and analyzed and appropriate measures are in place to implement changes.

CaptureSo you have your radar on and are monitoring your project. You can easily knock off the insignificant asteroids by balancing the small changes and handling the manageable issues – but now something big is approaching and it may impact the scope of work, dates, cost, etc. to the extent that the project will not be delivered as expected. 

What now?  Do you just incorporate this considerable change?  After all, you are in charge and you have access to the schedule. Your project staff is aware and accepting of this change.  Why waste any time analyzing and documenting it?  Perhaps it’s inevitable, so you are certain it has to be done.  After all, everyone knows about it and you have no choice. Maybe this change has come as a mandate directly from your sponsor. So just do it?  The answer is NO.  Regardless of the reasons behind the change, or who has initiated it and informally agreed to it, you must first complete an analysis so you can demonstrate formally the impact to the project.  This will lead to:

  • A full comprehension of all areas of impact
  • An assessment of the bearing this may have on other projects
  • An opportunity for team members and stakeholders to understand the change, the impact, and provide their input
  • An understanding if the change will affect other requirements
  • An awareness for your project staff, and their management, on new expectations
  • A re-planning period to incorporate the change and adjust dates appropriately
  • A formal agreement of the exact change, and resulting impact, by the project leadership

Your organization may have a method for tracking project change requests.  This may be via a form or in an automated collection tool.  If your organization does not have a project change request method that you are expected to utilize, consider creating a standard form or automated log for your projects.  The information you gather should comprise of the following:

  • General Information: Project Name, Date, Project Sponsor, Project Manager, Request Number (to allow you to sequentially track the requests), Requestor Name, Date Submitted.
  • Request Status: Change Request Status (Open, Approved, Rejected), Date Finalized
  • Approval Information: List of Required Approver Names, Signature or Tracking of Approval, Date of Approval.
  • Request Details: Description, Benefits and Impact to the Business
  • Impact Analysis:Assigned Resource (who is completing the analysis), Impact to:
    • Scope,
    • Cost,
    • Schedule,
    • Resources,
    • Documentation (that which is impacted by the change, or which will need to be modified because of the change)
  • Log: Stating discussions and activities related to the change

One important concept to understand from the formal change request is that it is documented and it is approved (even rejected in some cases).  Values of this include:

  • Changes can be requested and expected to be deployed without the requestor being aware of the consequences. It is not unheard that once a full analysis is complete, and the documented impact analysis is placed in front of decision makers, that the change is rejected in favor of keeping the project on its original track.
  • An approval of the documented impact assures that your project leadership is in agreement and on board with the request. 
  • This approval becomes the mechanism which authorizes you to set new baselines on project dates, work effort, and cost. 
  • Formalizing the change request is beneficial to you, the project manager.  If you go about allowing changes without a formal review you are doing a disservice to your organization and yourself.  Your job is to keep the project on track and if a deviation occurs, you will benefit by documenting the impact and receiving approval to incorporate the change. 
  • Providing documented evidence should questions arise as to why a deliverable or date was not met as originally expected. You will also find that fewer questions will arise due to the fact that a formal change request acts as a great communication tool and will result in changed expectations. Why wouldn’t you want that?

A final factor to consider is watching for any changes that are sneaking in under the radar.  Take a few minutes periodically to review the project scope and requirements to assure that what is occurring is in line with what is agreed upon. 

Let’s face it, if a project were to be perfectly planned, organized, and scheduled, with no issues or changes, the execution of the project would run smoothly without the need for any project management!  When have you ever been involved in such a project?

Don’t forget to leave your comments below.

Brenda Hallman has over 15 years of experience in project management, most recently in the Project Management Office at Main Line Health where she is responsible for standards, tools, mentoring, education, and program development for project management staff.  Ms. Hallman has a Bachelors of Science Degree in Computer Science and Mathematics from Edinboro University, a Masters Degree in Business from Penn State University, and a Masters Certification in Project Management from Villanova University.  She has worked in the information services arena initially in software development and later in project management.  She is PMP certified.

Project Managers are Change Managers

Written by George Pitagorsky on . Posted in Articles. 3 Comments on Project Managers are Change Managers

PTimes_Feature_Jan26Project managers, to be effective, must be competent change managers.  Often, projects to introduce new or changed products or processes or to put on an event are planned without appropriately considering the change that the project result will cause in its environment.  Let’s discuss change management (as opposed to the control of changes that occur in scope and other aspects of the project) and see where it fits in the context of project management.

Two Kinds of Change

There are two principle types of change – intentional and unintentional. 

Intentional change is change we make happen.  It is planned and actively managed.  Intentional change is brought about by projects.

Unintentional change is change that seemingly just happens. 

But, nothing just happens.  Everything has a cause under a set of conditions.  The causes may be initiated by others or occur randomly, as in a storm.

One person’s intentional change may, and often does, result in unintentional change for those who are subject to the change’s impact and in the form of unexpected ripple effects.  As an initiator of intentional change you must do your best to predict and be ready to manage the unintentional change that occurs when you change something in a complex organization or environment.  Accept the reality that you cannot completely control and predict the outcome because of the complex interplay among people, processes, organizations, cultures and other factors.  You could say that a big part of risk management is identifying and handling risks of disruption caused by the performance of projects and the delivery of their results.

Change Management

“Change management is a systematic approach to dealing with change, both from the perspective of an organization and on the individual level. A somewhat ambiguous term, change management has at least three different aspects, including: adapting to change, controlling change, and effecting change. A proactive approach to dealing with change is at the core of all three aspects. For an organization, change management means defining and implementing procedures and/or technologies to deal with changes in the business environment and to profit from changing opportunities.”[1]   

Managing change is a project in itself.  Sometimes it is treated as separate project, for example a project to change the attitudes of customers by instituting new customer service procedures or to implement a new process to improve performance.  When projects are seen in this light, it is most likely (though not guaranteed) that the human aspects of change management (avoiding and managing resistance, providing time for the acceptance and integration of the new into the existing environment, etc.) will be integrated into the project. 

However, we see many technology and product development projects and even process change projects that do not fully address change management issues.  For example, consider a project, initiated by a business or government agency organization to implement a technology innovation (a new and improved computer based system).  The project is viewed as an IT project and as such put under the management of an IT project manager with the charter to deliver the new system.  To her the new system is basically the software and maybe some user documentation.

In a healthy situation, this project would be a sub project within the broader project or program to improve the organization’s performance.  Ideally there would be a competent PM at the higher level to whom the IT PM reports or at least must coordinate with.  The higher level project or program plan would include the IT sub-project plan and would address the change management issues.  It would ensure that there was coordination between the IT project and the related business projects (developing business processes, communicating, training, etc.) and that there was a risk analysis regarding the change impact of the implementation on the environment and its people.

In an unhealthy situation, and I have seen and heard of many, there may be nothing more than lip service regarding the implementation and the change it implies.  Sometimes business leadership and IT leadership as well, act as if they believe that there is some magical process that will cause the new system to appear and be immediately integrated into the existing environment. 

As PM’s you have the responsibility to look at your project realistically in the broader context of the organization and to advise business leadership of the need to ensure that change is managed appropriately to ensure the delivery of the benefits that justified the project’s initiation.  If you do not, you run the risk of delivering a lovely product that is never used or never reaches its potential.  That means your project will be considered a failure.

Become a competent change manager.

Don’t forget to leave your comments below.