Skip to main content

Tag: Innovation

3 Reasons Value Needs to be at the Center of Your Project Triangle

Over the years, I’ve helped many teams find success by identifying and removing roadblocks.

One roadblock that seems to be appearing with greater frequency is “project prominence”— an emphasis on the project over the product or solution being delivered. Teams spend so much time and energy debating, controlling, managing and measuring the project process, that they lose sight of the product and the value the project is looking to deliver. The needs of the end-users and the goals of the organization become secondary.

The difference between project and product might seem subtle at first, but it becomes quite obvious in practice. The Project Management Institute (PMI) defines a project as “a temporary endeavor undertaken to create a unique product, service, or result.” The product is the unique output of a project—the project builds the product. Many teams do not think of their solutions as a product, but the definition of product is quite broad including tangible items that can be sold in stores, as well as new software, bug fixes, process enhancements and really anything made to be used or sold (Merriam-Webster).

Related Article: Feature Thinking vs Value Thinking: What’s the Differernce and Who Cares Anyway?

In practice, teams that emphasize projects:

  • focus on team operations
  • measure project phases, % complete, documents, timelines, deadlines, budgets, bugs, resources, etc.
  • debate how to optimize project operations
  • make decisions based on the team’s needs

Whereas teams that emphasize products:

  • focus on value
  • measure value delivered, end user satisfaction, speed to value, and learning
  • debate how to make a solution more valuable to the end users and the organization
  • make decisions based on end user needs and/or strategic goals of the organization

One way to reduce the emphasis on projects is to help your team rethink the Iron Triangle (aka the triple constraints of project management). The standard iron triangle usually looks something like this:

wicksept1

This approach assumes quality is achieved by controlling/balancing schedule, cost, and scope. If any of the constraints spiral out of control, the quality of the solution will suffer. If scope gets too big, schedule and resources (cost) must increase or the project quality will suffer. If the schedule gets too tight, the scope needs to be reduced. If the project overruns its deadlines (schedule), the cost will go up. You can’t change one, without impacting the others.

But, what if we modify the Iron Triangle to this:

wicksept2

Is this really different? Is it just semantics? Aren’t quality and value really the same thing? They aren’t the same! Value adds a dimension to quality—emphasizing that the quality of the solution matters only to the extent the user and organization derive value from an increase or decrease in quality. Keeping value at the center shifts everyone’s thinking away from the traditional project management approach to a product approach. Cost, scope, and schedule are only as important as the impact they have on the value delivered. I’ve found that putting value at the center of discussions about schedule, cost, and scope helps teams in 3 ways:

Teams Stay Focused on the End User

When quality defines success, it becomes possible to deliver high-quality solutions (minimal defects, no missed deadlines, no cost overruns) that no one wants or needs. That’s why usability, usefulness and/or value need to be part of the discussion.

Product value provides a strong foundation for every project. Strong teams start each project by exploring context in terms of product value and keep questioning value throughout the project lifecycle.

Teams Make Better Decisions

The value perspective helps you make better decisions throughout the project lifecycle. Teams that make decisions based purely on cost, schedule, and scope, miss out on opportunities to maximize value. It might be ok if the project goes over schedule and over budget when the team discovers additional scope that dramatically boosts value. It might be ok to miss milestones or leave parts of the project incomplete if those components do not provide value, or provide minimum value compared to the required cost and resources.

Strong teams minimize project metrics focused on operations, and create useful data that gauges cost, schedule, and scope in terms of product value to the end user and the organization. When value is already embedded in the data, value becomes the driver of decision instead of process quality. Teams stop making decisions that benefit them and begin to develop empathy for the end-users.

Teams Become More Agile

Putting value at the center of all discussions and decisions is the easiest way to bring agility to your project. The focus on product over project helps teams adapt. They embrace changes with confidence because the “why” makes so much more sense when change is discussed in terms of the end goal (user satisfaction) rather than the process. It brings relevance and context to change.

High performing product teams have a shared understanding of value that makes the need to change obvious. Teams become more adaptable and efficient as they streamline processes to focus only on what needs to be done to deliver a high-value product.

So, how do you bring value into discussions about timeline, budget, resources, documents and deadlines? Frame questions with value:

  • How do these metrics measure end user value?
  • Why is this deadline important to the end user?
  • How does this deadline maximize value?
  • Is this deadline early enough to leverage the value the solution provides to the end user?
  • How much are we willing to spend to provide this value?
  • What do we need to learn to increase the value we can deliver?
  • Are we spending more than the value the solution will apply?
  • Do these project tasks/documents provide value to the end user?
  • Do we have the right resources to deliver value to the end user?
  • What is the smallest scope needed to provide value?
  • Are there areas of scope that don’t provide value? Is this just enough to provide value and meet end user needs?

’m not saying that project operations, methodologies or frameworks are evil. Instead, I am encouraging you to take a look at your team and determine if you have a project prominence roadblock. Does your team emphasize project operations at the expense of product value? Your outcomes will improve dramatically if you let product value lead and smash through that project roadblock.

In the Age of Cloud Computing Business Analysts Are More Essential Than Ever

Almost everywhere you go in IT these days, the talk of the town is about cloud: what it is, why it matters, how to get there.

This comes at a time where the market is ruthlessly driving down costs concurrently with increasing demand for delivery of information.

Cloud is emerging as a way of making a business organization more agile, nimble, and efficient so that it can quickly meet business needs.

In this rapidly changing environment, business analysts are becoming vitally important in helping to guide the transformation that is underway. Their role as agents of business change places them in the eye of the storm when it comes to cloud initiatives.

Related Article: Software Solutions: Should I Outsource, Buy, or Develop In-House?

So how does a Business Analyst prepare for cloud computing? First, it is crucial to understand precisely what cloud is. Second, it is important to understand what the challenges and pain-points caused by a transition to cloud. Only then does it become clear how important a business analyst is for addressing the important issues raised by cloud.

So what is cloud?

Cloud computing is often simply (and wrongly) defined as a way by which a 3rd party vendor hosts IT infrastructure that runs applications, instead of having the IT infrastructure owned and hosted by the company or organization using it. While sometimes true, this definition is overly simplistic and not always accurate (for example, a company could own a “private cloud” itself rather than using a 3rd party.)

For a more complete definition, we can look to the National Institute of Standards and Technology (NIST) Special Publication 800-145. According to the NIST definition, “cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.” (Notice there is no mention of 3rd party providers.)

Let’s parse what that means. The NIST definition calls for five essential characteristics for cloud computing:

  1. Cloud provides ubiquitous, convenient, on-demand access. This means that cloud computing is self-service and available all of the time.
  2. Cloud provides for broadly available network access. Computing capabilities are accessible via the network rather than through hard cables, and can be accessed by any relevant client (PC, mobile phone, tablet, etc.).
  3. Cloud computing allows for resource pooling. When an organization doesn’t own computing resources exclusively for the use of specific applications, those resources become available for use by other organizations and applications. Resources can be dynamically allocated and re-assigned based on changing consumer demands. (This contrasts with the traditional model of computing resources that sit in a data center, which collect dust when not being actively utilized.)
  4. Cloud provides rapid provisioning and release of resources with minimal effort or provider interaction. When there is a sudden spike in the volume of demand for an application, it should continue to run quickly and smoothly through rapid allocation of resources behind the scenes without the need for human intervention.
  5. Cloud involves a metered paying model. Implicit in the definition of cloud is that someone has to pay for all of this. Rather than payment being for the purchase of equipment for a data center, the payment is for actual usage–usage for a number of servers, processor cores, terabytes of data, the amount of bandwidth used, or whatever else is relevant to the service.

Another thing to know about cloud computing is how it can be deployed. There are essentially three models:

  • Software as a Service (SaaS): provides functionality for end users, often with a per-license structure and with relatively minimal customization of the front end. The vendor runs everything. Gmail and Microsoft Office 365 are examples of SaaS.
  • Platform as a Service (PaaS): provides a platform upon which applications can be written and used. The vendor runs infrastructure, middleware, and operating system and you manage your own applications. Google App Engine is an example of PaaS.
  • Infrastructure as a Service (IaaS): provides core infrastructure as a utility service. The vendor runs infrastructure only; you manage everything else. Amazon Web Services is an example of IaaS.

A simple way of keeping the deployment model straight is to think of a railroad. The rails are the infrastructure, the train cars are the platform, and the products being carried are the “software” service.

Why is everyone moving to the cloud?

Cloud is often touted as the answer to reducing costs because it offers a number of benefits. The shared nature of resources means there is greater utilization and use of the computing resources you actually consume without having to pay for or maintain what you don’t use. It also offers advantages in terms of requiring less space along with the electricity and cooling necessary. It forces a simpler, more centralized management approach of computing resources. It also outsources the maintenance of commodity services not part of an organization’s core mission for things such as websites or email service. It also places responsibility for maintaining computing resources and their continuity of operations in the hands of experts who provide that service for many customers.

What does all this mean for a Business Analyst?

Consider some of the business problems that arise when we move away from a model where the applications supporting an organization’s processes reside on traditional, fully owned, dedicated computing resources.

  • How do you identify which business services and processes should be moved to the cloud?
  • Does a business really want its redundant, inefficient, or bloated processes and applications to be moved to the cloud where usage is strictly metered? If not, how do you make the identified services and processes cloud-ready?
  • What requirements, policies and governance should be implemented to guarantee performance, privacy, security, and quality of business data?
  • How will performance be measured and monitored, and by whom?
  • What kind of agreements (called Service Level Agreements or SLA’s) must be negotiated and monitored with cloud providers to ensure that the service does what it promised to do?
  • What kind of cultural challenges will arise from moving to the cloud, such as resistance to change or concern over lost jobs?
  • How will cloud applications and supported business processes integrate and interoperate with the rest of the organization’s processes that may remain on traditional computing?
  • How will legacy assets be decommissioned once their corresponding functions are moved to the cloud?

Business analysts will play a key role in addressing each of these problems and more, since nobody is better situated to pave this new path between business needs and IT implementation. It is therefore crucial that Business Analysts begin developing a cloud competency whether or not these issues have already arisen in their organizations.

There are five key things Business Analysts can do now to help prepare them and their departments for cloud.

  1. Educate yourself. There is additional NIST guidance about cloud and a lot more to know than what can be covered by this article. Learn about the different deployment models and cloud computing environments to begin understanding the possible options you could leverage for your organization.
  2. Take a holistic view of the enterprise. Now more than ever, a business analyst must take a 360-degree view of the enterprise when analyzing business process re-engineering. With cloud metering of usage, business processes must be aligned and made efficient wherever possible to eliminate duplication and waste. This happens best when the needs of the entire business are kept in mind rather than just the needs of a local business unit.
  3. Be prepared to address the issue of control in your requirements. The most burning issues for cloud revolve around control: ensuring performance of the infrastructure, continuity of operations should there be a need for disaster recovery, and security of data and application assets. Giving up the control provided by owning infrastructure assets is bound to be culturally difficult, but be prepared to explain how there are ways of mitigating these concerns to the level of acceptable business risks.
  4. Know how to measure. In a metered environment, everything about cloud comes down to measurement of performance. How much uptime was there? How fast is the application running? How much bandwidth was consumed? What is the Return on Investment of a new cloud platform? Your organization better be ready to choose, track, and report on all essential Key Performance Indicators. Many business organizations are not all that great about measuring their own performance. That needs to change before cloud computing can truly shine.
  5. Provide natural leadership. As you learn about cloud, you will become a thought leader on how best to acquire and manage it. Whether it’s implementation of SLA’s, development of cloud policies, making business processes cloud-ready, or writing cloud-specific requirements, you can be in the driver’s seat in making choices to maximize your organization’s success.

For current business analysts, the next few years will provide many opportunities for career advancement as long as skills are kept current to be valuable in the age of cloud computing. For new business analysts seeking to enter the field, there will also be more opportunities than ever to help fill increasingly critical roles in business organizations capitalizing on the advantages provided by cloud.

8 Tips for the Newbie Business Analyst

For many of us, a new experience comes with varying degrees of anxiety and nervousness. This is particularly true if we have lingering doubts as to our ability to do what is being asked of us – even if such doubts have no basis. Moving from a job where you knew what to do like the “back of your hand” to one where the learning curve is steep is one of those nerve-wracking moments that test the mettle of any business analyst. Of course, the extent of your anxiety is minimized given your years of experience and success stories as a business analyst. That said, it is critical that as a business analyst entering a new role or job position you showcase confidence. Let your stakeholders know that you know that you can deliver the results they need even if you do not know their business like the “back of your hand”. Your work will speak for itself! It’s only a matter of time before you too become a domain expert.

I want to give a few suggestions to any business analyt who might find themselves in the “newbie business analyst” position.

1. Come to the job armed with a set of tools and techniques that you can readily transform into something of value to immediately show your stakeholders that they made the right decision when they chose you for the job.

The very first assignment should be done so well that it not only pleases your team leader but demonstrates to stakeholders that you possess the ability to clearly detail the business needs and value-added approaches to deriving a solution.

When I changed my job of over 18 years to take up a job in an institution that I knew little about, one of my first assignments was to assist the insurance arm of the business in implementing an electronic document management system. I started by understanding the process from existing team members, then went on to observe the process to prepare a presentation with best practice information to show team members time and cost savings they would achieve by implementing such a system. I also provided high-level process flows and steps showing the integration of the document management system in the business’s workflow.

I will not tell you that it was smooth sailing, but the quality of my work was apparent, and the stakeholders were able to use the information to present their case to the Board of Directors, who approved of the electronic document management system.

2. Be prepared to go above and beyond the call of duty.

While completing the task of assisting with the online document management system, the business was thinking of having clients complete and submit a form online, which they would use to give the client an estimated insurance quote. So I took the opportunity and did the additional work to show the business how an online insurance quote system would provide clients with even greater value instantaneously while obtaining contact information that the business could use to follow up and sell their services.

3. Be of no reputation.

Do not surrender your dignity but adopt an attitude where you care more about serving your stakeholder than explaining to people why you are a business analyst. Your work will speak for itself. People sometimes do not see the importance of a business analyst until they have a task to accomplish and realize how the work of the business analyst brings structure, organization, as well as diagrams that give a better understanding of the issue. When you hear negative feedback, analyze the truth of it, strip away what you can learn from it, apply the learning and disregard the rest. Every experience will make you a better business analyst and sometimes the feedback, though negative, is true and is an opportunity for you to change something about your attitude or approach. Believe me, I know. During the document management project, I learned that the importance of clear communication and the power of an organization’s culture is not something to be taken lightly.

4. Complete company sponsored courses that will help you to understand more about the business.

You will have a lot of work to do but in the midst of it find the time to complete any company sponsored course or read up on the business to understand how it works.

My new job was with an investment company with a banking and insurance arm. My previous company was quasi-government and dealt with mortgage financing. To say I knew little about the operations of my new job was being generous. However, I jumped at the opportunity to complete a securities course that opened my eyes to the nature of the business. This knowledge served me well in my next assignment that mostly had to do with the core business.

5. Become genuinely interested in team members and their roles at all levels.

Get to know people – from the security officer to the CEO (to the extent that you have the opportunity to) – and understand how their role contributes to the bigger picture of value and profits. People will willingly share their knowledge if they understand that you genuinely care about making their work simpler and easier, and are there to improve the business. The best ideas or feedback come from the people who are engaged in the work on a day-to-day basis. Getting the feedback is so much easier if you form a good relationship with fellow team members and never adopt an “us against them approach”. A business analyst should assist in making it easier to implement change, not turn people off by dictating change.

6. Know when to keep silent and start by asking questions.

Never assume or use preconceived notions as a basis for interacting with your stakeholders. Silence does not mean “dumbness”. When you’re new, you learn a lot more through listening and asking questions than by just talking. Don’t just talk with the intent of letting people know that you know. You’ve already shown your expertise because you’ve been hired. Even if you got the heads up about stakeholders, use that to guide how you present information to them, not to develop a negative attitude towards them.

7. Accept when you’re wrong.

You are a business analyst, not a perfect human being. You won’t get it all at first, and you will make some mistakes along the way. Don’t be too hard on yourself. Don’t explain your error away – even if you have an explanation, accept where you’ve erred, apologize if you need to and move on. In apologizing, state what went wrong and what you have done to not repeat the error. Misunderstandings will occur – we can’t help ourselves. However, a placated stakeholder now can be of great support for future tasks. Leave your stakeholder believing that you are still the right person for the job.

8. Be appropriate, functional and relevant.

Every working environment is different. Yes, you have a plethora of templates, tools, and techniques but they should operate as the universe from which you choose based on your environment. Don’t overwhelm your stakeholders with everything. Tweak your templates so that they address the needs of your current environment.

My previous job was very structured and formal. My current job is less structured with some aspects of informality. Here, stakeholders want to immediately see what you’re talking about, not get lost in concepts, theories, and templates. It was my duty to look at the templates I had and modify them in such a way that made it easier for stakeholders to make decisions. Don’t get boxed into template thinking. Sometimes, all that is required is a simple email! You don’t want to use a sledgehammer to kill an ant!

When I wrote my first requirements document, the IT department was so appreciative of it and the IT business analyst decided to use aspects of its layout in the preparation of her requirements. At another time, in order to get a decision from a stakeholder at a senior level, all I did was sent an email succinctly detailing the issues, pros, and cons. The executive confirmed that the email correctly captured our discussions and used it to communicate a decision.

As I said at the beginning of this article, being a newbie business analyst is temporary. Soon you will become an expert. Just keep doing well what you know and keep reminding your stakeholders why you are the best person for the job. All the best! Looking forward to your comments.

Leadership Lessons – Problems! Glorious Problems!

C. K. Chesterton penned a quote that I’m especially fond of, “It isn’t that they can’t see the solution. It’s that they can’t see the problem.” It’s one that constantly reminds me that there is always, without fail, an opportunity lying around somewhere. I just need to find a way to find it. 

That wasn’t a typo, I meant to type ‘opportunity’, I didn’t forget that this discussion was about ‘problems’. A problem is an opportunity disguised as a thorn in your assumptions. Fix the problem and you’ve moved yourself forward in some manner, large or small.

Because of how I earn my living, I get lots of feedback – more than a person normally gets in other lines of work – file folders filled to overflowing with feedback. The good feedback is great, I love it (great reading when I’m down in the dumps), it’s what keeps me motivated to keep going.  But it’s the negative feedback when people point out a problem, that’s the true treasure. Becoming aware of new problems, if we have the motivation to respond to them, is what motivates us not only to keep going but to start going in a new and improved direction. Problems are always doors to something better. 

Organizations don’t like problems. We shy away from them; we shoot messengers who bring them to us, we surround ourselves with 800lb gorilla problems no-one dares talk about.  We have terms describing cultural approaches to problems – ‘wilful ignorance’ comes to mind- and we have to legislate whistleblower laws to protect those who make problems public. Organizations let problems fester until there is no other option but to lance them like boils. 

When I originally wrote this article, Wikileaks announced that in January 2011 it would release documents disclosing a pile of ‘problems’ in a major US bank. Of course, every ‘major’ bank worried that their ‘problems’ would see the light of day and scrambled to either hide these problems more deeply or hopefully fix the problems as soon as possible. 

The irony is that whatever organization got their knuckles soundly rapped by Wikileaks… all of the organizations knew of these issues before Wikileaks, before someone else decided to take action. Organizations ignore problems that obviously need fixing until they are forced to act.

Not all problems fall into the category that Wikileaks exposes. Most of the organizational problems that readers of this article might encounter are more mundane, with less serious consequences. More in the line of  “our projects are always delivered late; it takes an inordinate amount of time to get things approved; our meetings are a waste of time; our customer service needs improvement etc.” 

Even these can become so much a part of the work environment that we become blind to them, hence my fondness of Chesterton’s quote. We are typically blind to most of the problems around us. We need some way to heighten our awareness of the invisible problems so that we can then, if we choose, correct them. If only we could place a bounty on problems, and in so doing, get everyone looking high and low for them! 

Many organizations have some type of suggestion program where they always encourage, and then sometimes reward, employees for bringing new ideas, usually in the form of ‘solutions’, to management’s attention. It’s a step in the right direction of constant improvement, but this strategy contains a hidden flaw. It usually, not always, requires that an individual identifies a problem and then comes up with a viable solution – often on their own. That’s a lot of work for someone who’s already overworked in these tough economic times. 

Here’s another idea – instead of requiring a solution – how about just identifying a prominent problem? The individual tagging the problem doesn’t have to solve it, just recognize that it’s worthy of solution. The problem is then passed along to a group of people who love solving problems, people like myself who see all problems as a personal challenge, even as an affront to our sense of order in the universe.

The challenge is still the fact that many problems just hide deep inside the “we’ve always done it that way!” bushes. It takes either a new set of eyes to see these opportunities, or a quickly annoying habit of constantly, incessantly, persistently asking “Why?” about every business process until inefficiencies (if they exist) are exposed. 

Borrowing a new set of eyes isn’t too difficult to arrange. Just make it part of the organizational culture to have people from one department work in other departments for short periods of time and report back what they see. The hurdle is for everyone to grasp that the observations, while they will sound like criticisms, are intended – from the very outset – as a way to get better at whatever it is we do for a living. 

As to the Why? Why? Why? Why? Why strategy? That requires someone with a peculiar personality. They must have both an analytical mind and a very very good sense of humour. The Why? Why? Why? Why? Why approach – especially about things that everyone takes for granted, takes some getting used to – a sense of humour can take the edge off just a little bit. 

© 2015 Peter de Jager – Reprinted with Permission

Leadership Lessons – Change in Seven Questions

What must we do to bring about a Change initiative as smoothly as possible? Communicate! Communicate! Communicate! 

How much, and for how long do we do this? Until we get sick and tired of the sound of our own voice – then we take a deep breath and a drink of water, and we start all over again.

Communication isn’t something that stops and starts; it’s a constant activity before, during and after any Change initiative.

This isn’t exactly news. We sort of get this. Ask any audience to tell you the secret to good Change and they will repeat back “Communicate, Communicate, and Communicate some more!” as if it was forcefully injected into their cerebellum. The problem arises when the questioning becomes a bit more detailed, “What exactly should we communicate?”

The response to that question is usually either a blank stare or the reasonable recitation of the reporter’s standby; Who, What, Where, When, How and Why. Not a bad start. If you’re writing a news article, then these are good solid questions. The Change Management problem requires all of those, and a few others besides. It’s not that the reporter’s questions are a poor tool; it’s just that they don’t address the peculiar psychology of the Change challenge.

For what it’s worth, here’s a carefully selected list of questions specific to Change Management. If we take the time to answer these, then we’ve covered the bulk of the key concerns of those facing the Change we’re contemplating.

1) Why?

This is the winner, the key question; it’s almost the only question worth discussing. If someone asks me to move from one side of the room to the other, or to stop using system ‘X’ instead of system ‘Y’, my response is always the same. “Why?” Understanding why a Change is necessary is the most important question we have about any Change. Without a good answer, we’re reluctant to do anything different.

There are lots of good answers to the “Why?” question. One good one is “Trust”. If I trust you and you ask me to do something, my trust in you might be sufficient to prompt me to Change. If that trust doesn’t exist? Then the reason for Change had better convince me, or I’m not moving from where I am.

2) WIIFM (What’s in it for me?)

The fly in the ointment for many organizations, “It’s not about you!” they cry as they bend over backward to avoid answering this question. Here’s the newsflash, as long as they are concerned about the WIIFM question, they don’t pay attention to any other information. More precisely, until that WIIFM question is answered, they can’t pay attention to anything else.

The best way to think of the WIIFM question is as a nasty, vicious guard dog, blocking the gate to our attention. Until that dog is thrown a bone, no information about the Change, sometimes not even the answers to the “Why?” question, is getting through to our reasoning process.
Even if we honestly have no information about the WIIFM question we must still acknowledge that the question exists and that as soon as we do have more information, we’ll get back to the audience.

3) Monday?

Assume, for the moment, we have returned from our strategic planning weekend with a wondrous, phenomenal vision of the future of our organization. Also assume, for the moment, that our ability to convince everyone that this is indeed the direction in which our organization should move, is up to the task. Assume that we’re silver tongued devils and get everyone on board, on the bus, bought in and generally all fired up. With me so far?

Now they have a question. What do we do differently, specifically and precisely on Monday (or next Friday…or next month… ) to start moving us towards the promised land of milk and ever flowing honey?

It’s a fair question. If we want people to Change, we must describe what they’re going to do differently in terms that everyone can understand. If we can’t, then we go back to the drawing board, our vision is flawed and unattainable.

4) Won’t?

What won’t Change? What will remain the same during this Change?

The problem here is that when we face a Change, all we see are the unknowns, we lose sight of the fact that only one ‘small’ part of our status quo is going to flux. That the rest of our surroundings will likely remain the same.

For example? When the accounting system is going to Change, we’re still going to report to the same boss, earn the same paycheque, receive the same benefits etc. In fact, most of our status quo will remain the same. This works for nearly all Change, the only time everything Changes is when we die, and then? It’s not our problem anymore. In nearly all other cases regardless of the size of the Change, nearly everything else remains the same.

5) Might?

What might go wrong during this Change? And what contingency plans have we put in place to mitigate those risks?

The worst thing we can do when heading into the uncertainty of Change is to insist that nothing can go wrong. That’s not only asking for the Gods to pay attention to us, but it also communicates to those around us that we haven’t really thought this through. Although if we’re looking for a sure-fire way to lose the trust of those who follow us, insisting, “Nothing will go wrong” is a wonderfully effective strategy.

6) Will?

What’s going to hurt?

Change hurts. That’s almost the ‘First Law of Change’. If we’re doing something significantly different, then we’re going to be at the bottom of the learning curve. Even if we pay close attention to training and support and fall back positions, we’re going to make mistakes, production will decline, and we’ll get things wrong. If we pretend that the Change will be painless, that it will be “transparent to the user”, then people will know we’re lying, or at least overly optimistic. 

7) Signposts?

Change doesn’t always happen quickly, sometimes it’s slow, almost glacial in nature – we need some way of measuring our progress towards a goal. Without feedback we lose both the motivation and the will to make sacrifices to move forward. The question on the table is, “How do we know we’re succeeding in our efforts?”

These aren’t the only questions we need to answer during a Change, but they’re crucial ones and if the answers aren’t forthcoming, neither will the Change. Stick them on the wall in front of you when crafting a Change message and ask, “Am I answering these? If not? Why Not?”

© 2015 Peter de Jager – Reprinted with Permission.