Skip to main content

Tag: Leadership

Management Consultants and PMO failures

Written by Abid Mustafa on . Posted in Articles. 4 Comments on Management Consultants and PMO failures

Having worked in the (Middle East- North Africa) MENA region for a number of years, it is quite disheartening to encounter PMOs that suffer from acute identity crisis and are locked in endless battles with other departments to prove their worth.

What is interesting to discover is that the usual culprit behind PMO failures i.e. the lack of executive support, is not the primary cause. The common denominator behind the failings of such PMOs can be attributed to the role played by management consultants in setting up PMOs. There are three distinct areas where management consultants have played an instrumental role in creating PMOs, with major structural defects and no matter how hard one tries to fix it, the defects remain as an indelible stain.

 

1.     Sowing the seeds of executive confusion

There is a perpetual confusion in the minds of the executive team about the roles, responsibilities and competencies of the PMO. This is borne by the fact that in most cases, the management consultants hired to launch a company or a new business line, focussed exclusively on establishing a PMO that exhibited the characteristics of a reporting function and nothing more.  In this arrangement, the status from different projects and programmes are aggregated, rationalized and then presented to the executive team for decision making. Usually, the chief executive officer presides over the launch meeting, acts as the overall arbitrator and takes decisions on how to move the launch forward. Hence, the executive team performs well as long as the company is in launch mode, but any departure from this model and the frailty of the PMO is swiftly exposed.

Many executives find themselves unable to step into the shoes of the project sponsor (previously performed by the CEO as the sponsor of launching the business) and take important decisions about projects under their stewardship. Furthermore, very few executives possess sound ideas about how a centralized PMO should function in a post launch environment. Therefore, it is only logical to find executive support lacking as the PMO transitions into its post launch life.

2.     It was never about the project methodology

During the launch phase, the consulting company pays very little attention to devising a project/programme methodology, standardizing project documents and templates, and mentoring PMO staff about performing roles other than reporting. Even the reporting suffers from the absence of a structured approach and sometimes there is too much dependency on ‘power point presentations’. Hence, post launch, the PMO armed only with colourful slides is ill-equipped to support or deliver projects and programmes. Rampant project failure usually follows and all attempts to rectify the dire situation are hopelessly unsuccessful. This is because the solutions employed to address the structural weaknesses are derived from the PMO’s launch experience. For instance, many executives assume that just because the PMO delivered during the launch phase, a similar approach (without tinkering too much) will yield positive results.

3.     Over reliance on launch centric roles and responsibilities

Another surprising discovery is that the roles and responsibilities, processes and governance structures executed by the PMO are based on its launch life. It is not uncommon to find ‘Launch PMO’, ‘Launch Manager’, ‘Launch Director’, ‘Launch Gate’, ‘Launch Project Life Cycle’, ‘Launch Check Lists’, etc. as part of  PMO’s lexicon. In some cases, only the prefix ‘Launch’ is removed from job descriptions and processes, but the essence remains unchanged. Subsequently, the PMO and its staff are unable to adapt to the pace of corporate life and find themselves on the periphery of project delivery. To remedy the situation, two typical solutions are applied. Firstly, ‘certified project managers’ are recruited and expected to deliver projects on time. However, in the absence of a sound project management methodology many are found floundering.

Secondly, expensive consultants with extensive experience in working with PMOs in launch mode are brought on board to rescue the struggling PMO. In some cases, consultants are hired from the same management consultancy that established the launch PMO and fail miserably when given the responsibility to turn around the fortunes of the ailing PMO. All of this, exacerbates the problem, and marginalises the PMO’s role in corporate life.

To be fair to management consultants, they are typically hired for their domain expertise and not for their PMO competencies. The PMO is a value-add that is thrown in as part of the consulting service and at no extra cost. This practice is wide spread across the MENA region, so much so that executives are often left wondering as to why there is an abundance of project failure  despite the successful launch (the launch of the company or business line is viewed as a ‘successful project’) of the company or the new business line. To avoid a repeat of such stories, executives would do well to scrutinise the PMO capabilities of their management consultancy, in addition to their domain expertise. Alternatively, they may hire a PMO specialist company that works alongside consultants in the launch phase and in the post launch phase ensures that a proper PMO, equipped with the right methodology and resources is established.

Executives would be wise to opt for a PMO company that specialises on a BOT (Build, Operate Transfer) model as opposed to a DBT (Design, Build, Transfer) model. As the BOT model is geared more towards ensuring that the concept solution works in practice and the project culture is imbued and transferred within the organisation.

Don’t forget to leave your comments below.

Abid Mustafa is a seasoned professional with 18 years’ experience in the IT and Telecommunications industry, specializing in enhancing corporate performance through the establishment and operation of executive PMOs and delivering tangible benefits through the management of complex transformation programmes and projects. Currently he is working as a director of corporate programmes for a leading telecoms operator in the MENA region.

Communication and Mindfulness

Written by George Pitagorsky on . Posted in Articles. 6 Comments on Communication and Mindfulness

Foundations for Effective Communication

Last month’s blog highlighted the need to speak up at the right time in project life to avoid problems and minimize the impact of those that are not avoided. In an earlier blog I discussed Improving Communication: Controlling Your Body Language and Tone.

This month we’ll explore communication techniques that can be used to make speaking up easier and more effective and enable the control needed to moderate behavior and speech.

Effective communication relies on mindfulness, emotional intelligence, right intention, basic facilitation skills, the right vocabulary and courage. Over the next few months we’ll explore these in the context of project work.

Mindfulness

Let’s start with mindfulness, the ability to be consciously aware of what is happening in and around you. It implies clear, objective observation. Mindfulness is the foundation for effective communication. It enables emotional intelligence and the ability to facilitate. It enables you to choose the right words and behavior for each situation.  Increased mindfulness has also been shown to promote good health, better memory, concentration and enhanced performance in general.

Mindfulness is cultivated by mindfulness meditation. It is a very simple practice, just comfortably observing things like your own breath, feelings, thoughts and mental constructs (models, beliefs, opinions, etc.). These are objects of mindfulness. Additional objects of mindfulness are the way other people behave, what they say and how they say it. In effect anything that occurs in or around you can be an object of mindfulness.  By observing these phenomena as objects the mind is trained to become more objective.  Objectivity leads to better decision making and that leads to better performance.

For an instruction on how to do mindfulness meditation go to http://www.pitagorskyconsulting.com/articles/article/6339267/106485.htm.

Why Mindfulness is Important

Mindfulness is a key to communication because it makes it possible to be responsive rather that reactive. If when faced with a stressful situation a person can feel his or her feelings before reacting to them, then there is the possibility of choosing what to say and how to say it. 

The ability to see and feel the reactions of others to what one says and does makes it possible to shift behavior, body language, tone and the content of communication to get the kind of response one is looking for. 

When faced with a challenging situation in which the desire to speak up about a sensitive topic is being blocked by fear or lethargy, it is mindfulness that enables clear thinking to arrive at the optimal course of action.  It does so because it enables a “step back” that separates oneself from her feelings and provides the “space” to decide. 

Typically, people are so identified with their feelings and emotions that they do not have, or even think they can have, the ability to decide. Anger results in scowling or yelling; fear in withdrawal and avoidance.  One becomes stuck in his or her conditioning.

Mindfulness meditation gives the practitioner the ability to see experientially that there is choice; the ability to break old habits and respond creatively and appropriately in every situation. Anger is felt as anger, fear as fear, but these emotions are not immediately converted into unskillful behavior.

Don’t forget to leave your comments below.

The Rights and Responsibilities of Project Managers

Written by Kiron Bondale on . Posted in Articles. 3 Comments on The Rights and Responsibilities of Project Managers

FEATUREJan11thIn many organizations, project managers are the Rodney Dangerfields – they don’t get no respect!  We regularly experience the tug-of-war relationship between project and functional managers, but the same challenges often occur between project managers and their team members.

Issues with this dynamic frequently stem from confusion related to their respective roles, but they can also be caused by a lack of understanding of basic rights and responsibilities.

While these should all be common sense, to try to address this root cause, a review of some “generic” project manager rights and responsibilities may help. 

Responsibilities:

  • Help team members understand the vision and objectives for the project and how its outcomes could benefit the organization and them.
  • Define objective expectations for a team member about how status updates, issues and risks will be communicated.
  • Walk team members through key project management artifacts covering scope and schedule so they can better understand how their work products fit in to the overall delivery of the project.
  • Actively engage team members in the project by involving them in scope definition, activity effort estimation, risk identification and analysis and any other appropriate planning (and re-planning) activities.
  • Challenge (or remove) unnecessary administrative hurdles from the path of team members to help them be as productive as possible
  • Provide regular, objective performance feedback for the team members to their functional managers
  • Regularly update team members on overall project status including expected outcomes and any approved changes to project objectives or constraints
  • Review the role of the project manager with team members so that they understand what is and is not “in scope”

Rights:

  • Team members should keep the project manager apprised of changes to their availability
  • As per the defined and communicated expectations, team members should provide the project manager with progress updates, and any other information that is key to successfully managing the project including identified changes to issues, risks or scope
  • If the team member has concerns or confusion about their assigned work, they should communicate this to the project manager and get their assistance to resolve these in a timely fashion
  • If part of the team member’s role is to disseminate project information to their functional area, they should do this and not hoard knowledge
  • If the team member has an issue with another individual on the project team, they should first attempt to resolve the conflict directly with that team member, and if that does not work, they should engage the project manager to assist

As Josiah Stamp put it best “It is easy to dodge our responsibilities, but we cannot dodge the consequences of dodging our responsibilities.”

Don’t forget to leave your comments below.

The Agile Project Manager—Do You TRUST Your Team?

Written by Robert Galen on . Posted in Articles. 2 Comments on The Agile Project Manager—Do You TRUST Your Team?

bob1

bob2

 

As an agile coach, one of my favorite expressions in response to nearly any situation I encounter in an agile team is—“trust the team” or “trust the process”. So here are a few examples of what I mean:

If you think the team has underestimated their work and are leaving velocity on the table, “trust the team”…

–          If they have underestimated they can always pull in more work. And you know, you could be wrong, so allow the team to sort through how they understand, size, and execute their work. They’ll appreciate the trust you’ve given them and will invest in doing good work.

–          If you do see poor estimation or poor execution & adjustment, then bring this to the attention of the team within their retrospective. Give them examples, but allow them to explore the most effective way(s) to improve.


If you feel that the team isn’t working hard enough or are committed enough to their work, “trust the team”…

–          Unless you’re a direct member of the team, it’s fairly presumptuous of you to assume they’re sand-bagging and not working hard. Or thinking that they lack commitment. Rather observe how hard they do work, handle their challenges, and deliver on their sprint commitments. Assume that the wonderful professionals you’ve hired are just that—hardworking, honest, and professional.

–          And remember, just because people are putting in hours, that doesn’t mean they’re doing good work or working hard. It just means you have their butt in their seat…not their brain in the game.

If you feel that quality is poor and it isn’t improving sufficiently or you feel that the team isn’t taking product quality seriously, “trust the team”

–          Ensure that your concerns are visible to the team and that they’re looking into root cause within their retrospectives.  However, let them tailor their activities to improve deliverables each and every sprint. Explore objective data on their defect & quality deliverable trending with them. Give them clear and complete done-ness criteria. BUT, allow them to discover how to do a good job as a team.

–          Agile is not a magic formula. It cannot take a crappy product and, simply because you’re ‘agile’, remove all technical debt and bugs overnight. Improvement takes serious effort, commitment, and time. No silver bullets allowed!

If you’ve got a fixed date software delivery to make and you wonder if the team is going to get there, “trust the team” and “trust the process”

–          First of all, solid agile teams make everything transparent. Secondly, they approach delivery in iterative chunks. Put these two together and you’ll actually get a heartbeat of how well the team is meeting your projections & needs. If they aren’t, then you get the chance to negotiate scope trade-offs with them.

–          Agile projects can ALWAYS hit fixed date targets with fixed cost & quality goals. And they can ALWAYS deliver a set of your highest priority features. The variable in these situations though is scope—so you must be prepared to pare back scope via dropping low priority features and making micro-adjustments to other features—generally delivering Must-Haves over Nice to Haves.

If you feel that the Product Owner isn’t making good decisions surrounding feature priority, “trust the process”

–          The Product Owner will get plenty of feedback in the Sprint Reviews as to whether they’re focusing the team on the ‘right’ features, at the ‘right’ time within the flow of the project. The key is to get stakeholders regularly attending and to encourage positive and constructive feedback.

–          Quite often the Product Owner is a surrogate without real decision-making authority. That is NOT setting them up for success. Ensure your Product Owners are empowered to make decisions and have the seasoning and domain experience—to make the ‘right’ decisions.

These are only a few of the many real-world situations where we have a choice in how we actively demonstrate our understanding of agile principles and exhibit trust to our teams. You see, it’s not about saying you trust the team—it’s about truly trusting them and demonstrating that in in your words and actions. Next I want to explore a few, how shall I say it, trust anti-patterns or excuses that I commonly see.

bob3

There’s trust, and then there’s TRUST

Here are a few anti-patterns I frequently hear that indicate to me that the organization, leadership, project, management and other stakeholders don’t fully trust the team. I’m sharing them to broaden your thinking around trust and the ways we can frame it organizationally. By no means is this an exhaustive list, but more so a list that illustrates how our words don’t always necessarily align with truly trusting.

And of course this doesn’t apply to anyone reading this blog. So please just read it for future reference—in case you run into some of these anti-patterns…

Trust, but Verify

Of course I trust you, but I’m just simply verifying that what you’re telling me is true—as a simply checkpoint. Don’t worry about it, I’m just verifying…

Don’t be fooled, this anti-pattern isn’t about verification. It’s about distrust and the use of micro-management techniques to get into the heads of the team and control how they’re attacking the project. Yes, verification is important, but not daily. The Sprint Review is the ultimate verifier. Attend them.

The process is making me do it

Of course I trust you, but I need to get this information into the CMMI Level 3 artifact repository so that we pass our audits. Did you know that an audit was coming next month? Very serious stuff…

Another common anti-pattern is blaming distrust on the methods or process patterns that you’ve adopted as an organization. We’re CMMi Level 4, so I must have you fill out a detailed test results plan and sign at the bottom to confirm that you’ve tested everything you’ve said you’ve tested.  

Sure, processes carry some weight and responsibility. But this anti-pattern extends that as an excuse to hover over the team and control approaches & outcomes.

I’ve been doing this a long time and I know this path will lead to a disaster

Of course I trust you, but in my 25 years of experience, I’ve never seen a team deliver on a large scale refactoring effort. I simply don’t think it can be done…

While your experience is certainly valuable, times have changed and contexts are different now. Your team is exploring their own experience and finding their way. They’re establishing their experiences, and need to do that largely on their own…as you probably did.

I’m paid to prevent us from making mistakes

Of course I trust you, but my job is to prevent us from making mistakes and to develop the best products possible. It’s actually in my job description that I lead the team by the sheer force of my will and experience.

That I’m responsible and accountable for all of the results my teams produce. That leadership is about leading—showing team the way forward in practices and approaches. Trust does come into play, and of course I trust you, but only so far. Only when I have a belief that the outcomes will align with our organizational goals and my bonus plans.

bob4

True Trust

I have a favorite story I use for describing effective delegation. It goes like this—

Delegating is easy when you know how someone will approach the problem you’re delegating. Or when they’ve been asked to do the task many times before? There is no outcome risk.

But what if they would approach the solution differently than you? Or what if they might try a novel, but risky approach? Or, what if you’ve seen them fail at this sort of problem many times before? You ‘get’ the idea…but you still delegate to them. To me, this delegation, regardless of outcome risk, or approach, is true & pure delegation.

It means you trust the individual enough to encourage them to try something new. You’re enabling their creativity and you’ll be there if they ask for your help or advice. But they ‘own’ the task you’ve delegated to them and ultimately the results.

Now THAT’S delegation!

Adapt this definition and re-focus it towards trust. Then accordingly, start trusting your teams more. For example, here are a few transitional trust adjustments you might need to make—

  • Trust that they are estimating work based on the best information they have—and that the estimates are accurate given their context
  • Trust that when they run into trouble, they’ll let you know; otherwise they are making progress and don’t need your ‘help’
  • Trust that transparency and Sprint Demo’s will give you sufficient progress information—both on velocity and quality of their efforts
  • Trust that the team knows best in how to solve product development challenges related to architecture, design, and implementation
  • Trust that your Product Owner is effectively driving customer value—and are making the best decisions balancing business needs against team capacity
  • Trust that your Scrum Master is emphasizing done-ness, quality, and working collaboratively as a team. That if something needs attention, they’ll raise it as an impediment
  • Trust that when the team recommends refactoring a component of your system—that it’s truly broken and needs attention
  • Trust them to trust your own judgment and skills; that they look to you for high level guidance, goal-setting, support, and impediment resolution. 

Wrapping Up

True trust, like delegation, can be really hard. As leaders, many of us have engineering backgrounds and are natural problem solvers—so our efforts to engage the team with our ‘advice’ emerges from our own backgrounds, skills, and interests.

We’ve also been programmed not to trust our teams. The inherent dynamics of Taylorism and Scientific Management influences our behaviors when it comes to telling our teams what to do and hovering over them until they do it.

But trust is what a truly empowered and self-directed team needs from you. Of course you can inquire measure, establish vision and set goals, measure results, and provide feedback. Surely you’ve earned that right with your experience and role. However, try and give true trust as often as you can. You’ll see a huge difference in your teams’ performance and the results.

Thanks for listening,

Bob.

Don’t forget to leave your comments below.

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.