Author: Doug Jackson

5 Considerations When Taking an Enterprise Architecture Approach to Core System Transformation

Jackson Feb13

Many financial organizations find that it’s easier to just keep patching old technology rather than to make the kind of major changes to their core systems needed to become the business they really want to be. So, they keep pushing major transformations off, until one day the risks of maintaining the status quo become overwhelming.

Unfortunately, when legacy/core modernization projects are under time pressure, they often fall victim to the very issues that their solutions are meant to address—inefficient business processes, redundancies, and information not getting to the appropriate people at the right time.

Ensuring that one of the most challenging initiatives an organization undertakes is done correctly requires a holistic perspective that considers not just the IT questions, but also addresses the processes, resources, and more.

Taking an EA Approach

Leadership at one insurance company came face-to-face with these issues when it identified the number one risk to its future: aging legacy systems supporting critical policy administration functions. Its enterprise analysis approach had five key aspects:

1. Architecture First

To enable business growth and change, the insurer established an enterprise architecture (EA) group. The EAs completed a comprehensive inventory of the various capabilities across the company, including those involved in policy administration. This let them focus on the aspects of the business that would be impacted by the change.

2. A Product Prism

Product architecture is often overlooked in discussions of systems transformation. However, when looking at its product offerings, the team discovered that two major divisions within the organization structured their insurance products differently and used the same terminology in different ways. If not corrected, or at least identified early, this situation could negatively affect being able to bring in a new policy administration solution created to unify the company’s work.

3. Business Processes

The inventory the EAs created allowed for the creation of a hierarchy of the business processes currently in place. A significant portion of the project was spent eliciting and documenting information about as-is processes and where they could be improved. This is an excellent example of focusing on process and using software as an enabler of process, rather than building your business around someone else’s code.

4. Attention to Systems

When an organization looks to retire legacy systems, there needs to be a clear understanding of the interfaces and interactions that the new solution will need to maintain. Those connections include the links both internal to the organization and external.

5 Tools to Use

The amount and critical nature of the information gathered in this process is difficult to track using such tools as Word or Excel. A relational repository is needed for all enterprise architecture artifacts as well as for documenting and managing requirements and tracing them to business goals.

Next Steps

Transforming an organization’s core systems is not an easy undertaking, yet a considered, thoughtful approach can mitigate the risks and help an organization take a significant step toward achieving its long term vision.

Don’t forget to leave your comments below.

New Research Uncovers Five Top Issues that Lead to Requirements Problems

jackson July14It seems that the problem of challenged projects isn’t getting any better. Respondents to a recent survey indicated 62 percent of organizations experienced one or more challenges in over 30 percent of projects. Given the number of software and other critical projects that go over budget, get delivered late, or don’t meet business needs, requirements—a major contributing factor to project failures—continue to be a major problem.

Because of the persistence of the requirements problem, The Performance Institute embarked on a research paper to examine the answers to two questions:

  1. Why haven’t organizations been able to effectively address the requirements problem?
  2. In organizations that have made improvements, what actions have had the biggest impact?

Results Aren’t Surprising

The researchers’ findings were recently published in “The Problem with Requirements: Why is it Still a Problem?” . Interviews and answers uncovered five main issues that lead to the “requirements problem” organizations experience today:

  1. Organizations focus on the wrong thing. Software projects delivered results that failed to address a strategic business need were a predominant complaint. The misguided mission of “getting the work done,” instead of enhancing two-way communication with stakeholders about components needed to propel the organization forward, lead to problems.
  2. Not enough time spent on requirements. Time and time again, organizations reporting on challenged projects say that not enough time is devoted to eliciting requirements. Successful projects reported the opposite—that the time spent on requirements was “about right.”
  3. The wrong people “do” requirements. Often, the person who has the time to gather requirements is the person asked to define requirements. In some organizations the vendor is given the responsibility of documenting requirements. No wonder there are problems on these projects.
  4. Often BAs don’t have the right stuff. Research has found that just because someone holds the title “Business Analyst” doesn’t guarantee that a person is qualified to define and manage requirements for difficult, complex projects. Furthermore, holding certification in business analysis doesn’t mean that they are able to navigate successfully in this environment.
  5. Government contracts are too complex. The complexity of the contracting process made requirements problematic for some organizations. Delays between when a request is submitted and when the product or service is actually contracted often meant that the requirements information becomes Overcome By Events (OBE); resulting in a solution that does not meet the business need.

Conclusion

Despite the value of requirements to the enterprise, most organizations apply surprisingly little rigor to their approaches to requirements elicitation and management. Moreover, many executives continue to underestimate the impact of their requirements discipline on organizational success.

Don’t forget to leave your comments below.

When Too Long Isn’t Long Enough

Does Requirements Gathering Slow Projects?

In a recent social media poll, business analysts (BAs) reported that their top obstacle to success was the perception that requirements gathering takes too long. If you’re a BA and you haven’t heard this complaint, consider yourself lucky—it’s one that we frequently are asked to “fix” when we visit a client site.

The truth is that requirements gathering and requirements management—when done correctly—are essential to producing outcomes that meet the needs of users.  And, because the process is so necessary, it takes time.

The paradigm needs to change from “BAs write requirements during the requirements phase” to “BAs conduct business analysis throughout the project lifecycle, and the product of good analysis is high quality requirements information.”  In this new paradigm, everything is requirements related in some way: the goal of the project itself is a requirement, stakeholder needs are requirements, systems have requirements, etc. 

DougJune26th1

BAs believe (and analysts like Gartner agree) that more time, not less, should be spent conducting business analysis.

Here are a few good arguments to support what may at first seem like a somewhat unpalatable message.

The Invest Now or Pay More Later Argument

The reasoning behind this argument is pretty powerful and exists in most organizations.  Start with a general line of thinking—An incorrect requirement can have many aliases: bad specification, correction, bug, defect, test failure, or customer complaint; the different names correspond to when the problem appears in the project execution process.

Next, use the Voke graphic (below) or research from Forrester, Gartner or  another organization.  All reach the same conclusion; when you correct a requirement later in the project execution process, it costs more—a lot more.  In fact, the cost to repair a requirement grows exponentially as the project progresses.  This fact makes sense when you consider that correcting a data requirement after an elicitation activity often takes less than hour.  However, discovering, fixing, testing and re-launching a solution defect traced to that incorrect requirement can take over 100 hours during implementation.

DougJune26th2

The Quality Solution Argument

Part of the job of a business analyst is to carry the requirements “message” across the divide between the business sponsor and the IT development group.  Regardless of which side of the divide you reside, the phrase to use is “if I just spend a little more time” to clarify things for “those” folks, we will avoid headaches later.  This approach is best accomplished when you have a collaborator on the other side of the IT/business divide.  Ironically this is a best practice, and the more often it is done, the narrower the divide becomes…and the less likely the requirements message is to get shot.

The Better Backlog Argument

Your enterprise is probably working in some way with Agile.  If your organization is like most, an executive has probably complained that business change is not happening fast enough and Agile seems like a great way to address the complaint.  After all, who could possibly have issue with something called “Agile”?

A common illustration of the Agile approach is what is often called “the journey.” The illustration goes like this:  Instead of spending a lot of time mapping out the journey up front (i.e. the waterfall approach) SCRUM methods use quick sprints where you start in one point and end at another moving closer to the desired destination as it is known at that point in time (see Washington D.C. on the illustration to the right).  Once theDougJune26th3 team completes a sprint (see Terre Haute, IN on the map) it evaluates if the same destination is still desired by the business sponsor.  If so, the development team will work with the next user story in the backlog.

Agile is a great concept and one that works well if it is done right.  But as the BA you need to prepare for the journey by addressing two major pitfalls in the way backlog requirements are defined and managed.  The first pitfall happens when functionality is added in such a way that only partially satisfies the business requirement.  The other pitfall occurs when there are two alternatives which need to be evaluated to determine which is best for the intended user.  Selecting the wrong fork may reduce the overall experience for the intended user, though the SCRUM team provided exactly what the business requested.

More comprehensive requirements with frequent validation will mitigate the risks associated with both of these pitfalls, but the approach requires a bit of time up front verifying the journey as it progresses.  If your team has a customer advocate or user experience expert, these resources should support your justification for taking a bit more time to revisit the roadmap.  Tools BAs can use for verifying the journey often take the form of a business process model or storyboard.  Using either method will force stakeholders to think at a higher level throughout the project—time well spent, especially if you get an “ah ha” moment.  Document the experience and testimonial.  You will be ready when a sponsor asks you to sprint a little faster.

Five Tactics To Help Support Your Arguments

  1. Localize your argument that bad requirements are directly tied to poor outcomes. Conduct an anecdotal or simple online survey at the beginning of a project. Ask each respondent to think about his or her last project and “guestimate” how many errors could’ve been avoided if the requirements were clearer up front. You can also ask them to directly tie a defect to a poorly-defined requirement.
  2. Recognize—and work within—the divide that exists between the business and IT. The expression to remember to use with both sides is “if you allow me to just spend a little more time” to clarify things for “those” folks, we will avoid headaches later.
  3. Avoid placing blame. Some people, such as stakeholders, hold interests that aren’t directly part of the solution so it is natural that your project and its deadlines may not get his or her full attention. But don’t complain. Most people have long memories and will remember your actions on the next project. A variation that does work is to approach the individual directly, asking for his or her help. When we do this we often find that the person needs to be involved sooner with more frequent, low time commitment reviews.
  4. Sponsor a learning session. Get the help of a member of the PMO to talk about the need to step away from the traditional “requirements as a checkbox” approach and toward the idea that requirements are a continual process.
  5. Use patience, praise and food. Even professionals need encouragement along the way especially when tasks cannot be done quickly and easily. And remember people always learn better when food is on the agenda, so quid pro quo could involve a wheat wrap or a chocolate chip cookie!

Don’t forget to leave your comments below.