Can an Organization Ever Really Be Ready for Change?

Do you have one of those “favorite projects” in your archive of accomplishments, one that you feel you really nailed when defining the needs of the situation? One of my favorites goes back 10 years now – a Case Study in Enterprise Analysis that called for quickly gaining an understanding the scope of compulsory changes that impacted every role, location, and application in the systems infrastructure.

In the last decade the possibilities for virtual collaboration have expanded exponentially, and I’ve been thinking about what I might do differently. As a part of this retrospective I contacted my Client for feedback; his response in the category of “areas for improvement” triggered some ideas on how you might help your organization to be more ready for change.

The Project

After the huge organizational shakeup that marks the liquidation of a major insurance company, the new head of IT needed to quickly find and fill the gaps in current systems capabilities, and also shut down systems that were now obsolete. He knew he needed process analysis and was familiar with my work on Y2K; my former boss kindly volunteered that I was “in between” career opportunities and the rest is history. What started as one of those hallway conversations turned into an extraordinary opportunity to conduct Enterprise Analysis. I jumped at the engagement, and became an independent professional consultant for the first time.

Not knowing what’s around the bend calls for a certain agility

A devoted follower of Zachman Framework and business modeling notations, I formulated a plan to conduct top down, outside in analysis of the business situation to identify gaps, redundancies, and obsolescence, making recommendations on new processes and systems infrastructure. I had 3 months to figure out the people, process, and technology of this revamped organization.

Warming up to the task I collected existing process artifacts – some were even my own old work products – to map against the directives of the Court Order that was guiding the organization’s activities now, under the direction of the State Insurance Department.

In iterative workshops conducted in Philadelphia and New York I worked with Management, Staff, & IT, focusing on roles, processes, and supporting systems. Lots of ideas were circulating about how to handle existing agreements, new claims and lawsuits against the business, running off work in progress, etc., but above all we needed to follow the court’s guidelines, no matter how oblique. Yes, the very rules for our operation were still open to interpretation, and would only be resolved with time in front of a judge. I quickly recognized that flexibility was key, but only recently have I connected our situation with Agile Practices.

The Outcome

What Worked Well

As a consultant I tend to look at outcomes in terms of concrete deliverables. For this project the analysis work and recommendations were published in a high level overview presentation format and also as an electronic package of supporting material and project artifacts – charts, diagrams, and reports. The material loosely framed user stories for prioritization as the Project Office devised the initial operational and technology plans, and became a reference that was pulled out again and again over the years that followed, as exhibits for leadership meetings with Regulators, references for staff retraining, technical architecture and procedure manuals, to assess operational impact when introducing new technology like imaging. The inventories of processes, roles, and systems provided a foundation for forecasting and streamlining business activities over time. I’m proud of that body of work, what was accomplished so quickly in a highly ambiguous situation.

Room for Improvement: Stale in the Blink of an Eye

I do see now that there were shortcomings. While the analysis overcame vague business needs and pretty adeptly dealt with the “blue sky” aspects of our gaps in knowledge, the deliverables represented a static point in time, becoming inaccurate almost immediately. Although the project participants certainly had ownership of the analysis content and recommendations, no one was charged with ensuring that organization remained ready for more changes.

Years later when asked to retrospectively assess that initial work, the CIO had this to say about where the results fell short:

There is one major item that comes to mind. That is as the Liquidation proceeded we found out “we didn’t know what we didn’t know”, every step of the way was a corner we couldn’t see around till we got close to it and many times we were breaking new ground. Thus the question is should the analysis also have included a component on what to do as things change and new things come up both from the business perspective and the technical one.

Back then, we were so focused on figuring out what the elephant looked like that we didn’t pay much attention to its ongoing evolution. If we had instead attacked this business reengineering from a more Agile state of mind the organization may have been able to respond more rapidly to the evolving business challenges. Agile practices enhance an organization’s ability to handle emerging needs by using an iterative and incremental delivery approach. From the BABOK Guide (2009, 20):

Change-driven approaches focus on rapid delivery of business value in short iterations in return for acceptance of a higher degree of uncertainty regarding the overall delivery of the solution. These approaches tend to be preferred when taking an exploratory approach to finding the best solution or for incremental improvement of an existing solution.

If I Knew Then What I Knew Now

How could I have helped? The first thing that comes to mind is a Change Navigation Team prepared to carry forward the work as the business environment evolved, responding to change over following the plan.

As lead analyst I would focus more on the dynamic nature of requirements and implementation priorities, recommending an infrastructure for adaptation based on the value delivered. So it’s not just about how will you handle the changes you know are coming, it’s how will you respond to those that give you no warning.

Given a chance to do it all again, I would create a more collaborative environment for my project participants, putting in place a solid communication process as a part of the daily routine, and a framework for iterative facilitated analysis that joined the locations. Through our virtual team-building efforts – coming to consensus on common values – perhaps we could find smarter ways to decide on what to build and when.

For more information about this project, download the Case Study.

>> Learn the Business Analysis Process

An essential element of succeeding in a business analyst job role is understanding the business analysis process. We walk you through an 8-step business analysis process in the BA Essentials Master Class. You’ll learn a step-by-step business process that you can customize to meet your organization and project situations, how to create a timeline for a new business analyst assignment, and be prepared to handle the more common issues BAs face on new projects.

Click here to learn more about the BA Essentials Master Class

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.

Comments

  1. You’re welcome Alidad – I’m glad you stopped back. I was thinking more about how I could have used Deming’s PDCA. One way is with our process work. With a bit more effort we could have included data to drive an automated simulation – information about staffing, cost, throughput, etc. – which would have led to statistically informed decisions about personnel and support technology. Many modeling tools have this capability, including the one I was using then, Metastorm’s ProVision http://www.metastorm.com/products/provision_ea.asp By simulating different scenarios using the models you can predict key measurements, conducting a proof of concept without disrupting business operations or investing in experiments.

  2. Thanks for the great insight. I guess your point of the framework being static but the content is not is very interesting point. I need to think about it more.

    By PDCA I was more referring to your comment about what you would have done differently.

    And I agree that without a having clarity about the components, you never know where to go and what to fix.

  3. Hi Alidad. Thanks for your reference to the Deming cycle of Plan-Do-Check-Act http://asq.org/learn-about-quality/project-planning-tools/overview/pdca-cycle.html , which calls for carrying out a small scale study and based on what you find, move forward or re-plan. Later on we were able to stop and prototype new solutions, but the challenges in front of us when we began seemed monumental and the new mandates were already in effect. We did our best to progressively elaborate, leaving a “black box” where we weren’t sure how the rules would evolve.

    To answer your question, the framework may be static as long as the content is not. The cells contain functional, organizational and data structures – the models of the business and it’s information needs – and these will constantly evolve. For many organizations that’s an afterthought, and maintaining an accurate reference is a low priority. This is the point we missed back then. Without updating the information as transformations occurred, we were scurrying with each new initiative to learn how things had changed since we last had a look. This in turn delayed our responsiveness.

    To me, Enterprise Architecture puts the organization in context – the goals, functions, events, and relationships that are critical to doing business. These change all the time, and the job of the Enterprise Architect is to maintain an accurate picture, providing guidance in the design and evolution of an enterprise. I still feel an enterprise view was critical then and would be today. I’m not sure how an organization can adapt to change without having clarity around its components.

  4. Hi Joan,

    Very interesting post. I guess if you knew the Deming cycle back then, you could’ve helped the organisation injected it to their DNA.

    I like this part of your post “the deliverables represented a static point in time, becoming inaccurate almost immediately”. IMHO, This is by far the biggest challenges of our profession which of course Agile somehow a solution.

    I have a question though, with Lean and Agile as the talk of the time and the simple fact that Organisation means ongoing change(Moving target) do you believe that static frameworks like Zachman’s are still relevant? Do you think we still need an Enterprise Architecture in its traditional sense? and what is the countermeasure?

    Thanks again for sharing the great experience.

Comment

*

Before you go, would you like to receive our absolutely FREE workshop?

(No formal experience required.)

21689
21690

Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.