Tag: Enterprise

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

Written by Doug Jackson on February 16, 2015. Posted in Articles. 1 Comment on 5 Considerations When Taking an Enterprise Architecture Approach to Core System Transformation

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.

Strategy Spotlight: 3 Organizational Structure Risk for the Business Enterprise

Written by Richard Lannon on January 26, 2015. Posted in Articles. 2 Comments on Strategy Spotlight: 3 Organizational Structure Risk for the Business Enterprise

Recently I delivered a workshop on Risk Planning and Analysis for the Business Enterprise. I was asked about the various levels of risk within an organization. In response to that question, I explained that there are many levels of risk that could be organized along standard company structure. My preference is to use three structure approach – – strategic, tactical and operational.

Strategic Risk: Generally strategic risk is at the enterprise level and requires a business risk management enterprise plan. There are many models that can be used. At this level risk management, planning and analysis should be part of the strategic planning process. An enterprise risk management plan should be created that addresses strategic planning elements, cultural risk appetite and attitude, governance, stress testing, identification, measurement, response and control. These elements should be brought forward as a standard in the rest of the organization. On a regular basis the organization should complete an enterprise risk environmental scan to ensure they keep their business risk artifacts current.

Tactical Risk: This level of risk is at the project management level. Often it is part of the project management process for key approved initiatives. Its objective is the successful completion of the project while addressing risk concerns effectively and efficiently as possible. Often tactical risk analysis requires that the organization have a risk management plan that provides the guidelines as to how risk is to identified, qualified, quantified, responded, controlled and monitored. Guidelines should be provided by the business enterprise so that project teams do not create their own risk management standards.

Operational Risk: The here and now of any organization is the operational level. It is what happening with the frontline of the business from your customer facing employees, the manufacturing floor equipment and product assemblers, to the field maintenance people. Operational risk varies by company and by industry. One thing is for sure, operational risk needs to be aligned with business guiding principles to ensure people and equipment is functioning appropriately. For example, safety is a huge issue in a number of industries. Therefore, risk response mechanisms need to be put into operational place to minimize risk impact.

Risk management, planning and analysis are a huge discipline that impacts all levels of the organization. It is not something that is meant to be done neither in isolation nor with a single group. When you consider risk management consider all levels of your company. Maybe by putting together a solid risk management plan there will be a less of a need to carry a rabbits foot.

Don’t forget to leave your comments below.

Exploring Product Options to Arrive at Right Requirements

Written by Ellen Gottesdiener on February 25, 2014. Posted in Articles.

When is a so-called requirement really required? And is it the “right” requirement? The answers depend on many facets: stakeholders, value, planning horizon, and so on. This article explores using options as a means to identify high-value requirements, at the last responsible moment.

Our previous article in this series, “Turning Competing Stakeholders into Collaborating Product Partners,” describes stakeholders as product partners –representatives from the customer, business and technology groups who collaboratively discover and deliver high-value product solutions.

My Requirement May Be Your Option

Product requirements are needs that must be satisfied to achieve a goal, solve a problem, or take advantage of an opportunity. The word “requirement” literally means something that is absolutely, positively, without question, necessary. Product requirements must be defined in sufficient detail for planning and development. But before going to that effort and expense, are you sure they are not only must-haves but also the right and relevant requirements?

To arrive at this level of certainty, the product partners ideally start by exploring the product’s options. What do we mean by an option? An option represents a potential characteristic, facet, or quality of the product. The partners use expansive thinking to surface a range of options that could fulfill the vision. Then they collaboratively analyze the options and collectively select options, based on value.

During discovery work, the partners may find that some members see a specific option as a “requirement” for the next delivery cycle, whereas others consider it a “wish list” item for a future release. Such was the case in a recent release planning workshop. The team wrestled with a particular option, questioning if it could deliver enough value to justify the cost to develop it. The product champion explained why the option was a requirement—without it the organization was at risk for regulatory noncompliance. Once the others understood this, they all agreed it would be included in the release.

In a different planning workshop, the systems architect raised the option of using biometric technology to reduce security threats. After carefully considering a variety of factors, including the cost and organizational readiness, the team chose to defer the option.

Count to Seven

Both agile and non-agile teams often unconsciously limit analyzing the options. Many teams zero in on stories, learning about the users and their actions. Other teams dig into processes or data, or sometimes both of them. But every product has multiple dimensions, seven in fact. Discovering options for each of the 7 Product Dimensions yields a comprehensive, realistic view of the product.

Product Dimension	Description
User	Users interact with the product
Interface	The product connects users, systems, and devices
Action	The product provides capabilities to users
Data	The product includes a repository of data and useful information
Control	The product enforces constraints
Environment	The product conforms to physical properties and technical platforms
Quality Attribute	The product has certain properties that qualify its operation and development

Table 1: The 7 Product Dimensions Yield a Comprehensive Understanding of the Product

The previous article in this series described the Structured Conversation, where the stakeholders, acting as product partners, explore product options across the 7 Product Dimensions, evaluate the possibilities, and make tough choices based on value. Remember, every product option cannot be delivered right now.

Exploring across these 7 Product Dimensions prevents difficult downstream problems. A recent client was struggling with just such a blockage. Running their product on multiple platforms was causing delays that put them behind in their market. As they explored the Environment dimension, they considered browsers and database management systems possibilities. Their analysis factored in the most valuable options from the other six dimensions, including the location of the users, the actions that would be supported and the necessary data. They then selected a cohesive set of options across the 7 Product Dimensions to craft a candidate solution. They were able to make what had once seemed a difficult decision in a matter of minutes. By exploring across the 7 Product Dimensions, their painful problem was resolved with a clear, holistic set of requirements.

Figure 1. A product encapsulates a cohesive set of high value options
Image Source: Discover to Deliver: Agile Product Planning and Analysis, Gottesdiener and Gorman, 2012

Look Far and Near

The partners need to realistically determine when an option will deliver its greatest value.
Our previous article in this series outlined three planning views. The timeframes may vary from team to team, but general speaking they are as follows:

The Big-View is the long-term view or product roadmap (generally one to two or more years). The partners envision generalized, high-level options for the product. Options for the big-view could be considered “boulder” size, or in user story terms, as epics.
The Pre-View focuses on the next product release (say one or two months). To continue the analogy, these options are “rock” size, or user-story size.
The Now-View concentrates on the next product increment (from a day up to a month). The selected options are fine-grained, “pebble size” and defined in sufficient detail for development. They are no longer options but requirements, ready for immediate development.

An aside: We have used the “boulder, rock, pebble” analogy for many years to distinguish granularity in each view, for each of the 7 Product Dimensions.

An agile team keeps the product options “open.” In each view they wait until the last responsible moment to evaluate the options’ value and allocate high-value ones to the next planning horizon. They are prepared to adjust their choices for a variety of conditions, including changing market conditions, emerging technologies, and so on.

From Options to Requirements

Discovering product options enables the product partners to collaboratively and creatively explore a range of possibilities. This expansive thinking opens up product innovation, experimentation, and mutual learning.

By holistically exploring options for the 7 Product Dimensions the partners grasp the entirety of the potential range and can choose the options that deliver the highest value. Using the appropriate planning view (Big, Pre, Now), they narrow the scope. When an option is allocated for immediate delivery it is consider a requirement.

As a recap, we characterize a “right requirement” as one that is:

Just in time, just enough. It is essential for achieving the business objectives, in this time period.
Realistic. It is capable of being delivered with the available resources.
Clearly and unambiguously defined. Acceptance criteria exist that all partners understand and will use to verify and validate the product.
Valuable. It is indispensible for achieving the anticipated outcomes for the next delivery cycle.

In this series’ next article we focus on value—how the product partners define and use value to select options needed to deliver high-value products.

Don’t forget to leave your comments below.

About the Authors:

Mary Gorman, a leader in business analysis and requirements, is Vice President of Quality & Delivery at EBG Consulting. Mary coaches product teams and facilitates discovery workshops, and she trains stakeholders in collaborative practices. She speaks and writes on Agile, business analysis, and project management. A Certified Business Analysis Professional™ and Certified Scrum Master, Mary helped develop the IIBA® Business Analysis Body of Knowledge® and certification exam, and the PMI® business analysis role delineation. Mary is co-author of Discover to Deliver: Agile Product Planning and Analysis.

Ellen Gottesdiener, Founder and Principal of EBG Consulting, is a leader in the collaborative convergence of requirements + product management + project management. Ellen coaches individuals and teams and facilitates discovery and planning workshops. A Certified Professional Facilitator and a Certified Scrum Master, she writes widely and keynotes and presents worldwide. In addition to co-authoring Discover to Deliver: Agile Product Planning and Analysis, Ellen is author of Requirements by Collaboration and The Software Requirements Memory Jogger.

7 Steps to Kick-Start Your Strategic Planning Process

Written by Richard Lannon on January 28, 2014. Posted in Articles.

Strategic planning is an exercise in gathering and documenting information about the past, present and future of your business. Strategic planning helps determine where you want to go over the next few years, how you are going to get there and how to recognize when you’ve arrived.

One of the more common strategic planning approaches is Basic Strategic Planning (BSP). BSP uses a triangle approach and seeks to align strategic agenda items with the tactical reality of the organization.

Starting from the top, BSP includes the following steps:

Identify your mission statement. It is amazing how many organizations don’t take the time to develop this statement. A mission statement is foundational to all strategic planning work. An effective mission statement describes what the company does, provides insight into client value and captures the essence of your company.
Create a vision of the future. A vision statement should look to the future. After all, you can’t get to where you want to go unless you know where you want to go. Think ahead to three to five years from now and write your story. What is it that your organization has achieved? Tighten that story into a clear crisp sentence and share it.
Develop core values and guiding principles. Core values and guiding principles are foundational to your entire organization. Guiding principles are a set of accepted guidelines formed by the business that capture how your people act, work, make decisions, set priorities and conduct themselves. It is imperative to set and communicate core values and principles or else they will set themselves over time through employee habits.
Create long-term goals and smart objectives. Goals are general statements outlining what you want to achieve to meet your mission and vision and address any issues you are facing. For each and every goal it is important to identify strategies to achieve them. Objectives should be SMART; that means specific, measurable, attainable, realistic, and time bound. It is important that you make a distinction between long-term goals and smart objectives for those goals.
Establish an action roadmap with timelines. An action roadmap is a visual representation of your strategic planning items. It includes high-level agenda items, initiatives, champions and key elements. It includes the key areas that your organization will focus on in order to achieve its goals and objectives.
Build a communication plan. Communication plans should not be complicated and should be shared within your organization. It is important that time is spent determining the best approach for getting people informed as to what is planned and ensuring that they know impacts of not achieving the objectives. Consider printed plans, maps, high-level visuals, town hall sessions, etc. It is all about communication. Be visual, be creative.
Establish an implementation and monitoring plan. This is important to be successful. Organizations and teams fail because they don’t assign a top-notch resource to put together an implementation plan. Consider using a highly-skilled program manager or director to translate the strategic plan into tactical reality. Ensure that the rules of engagement are established and build a strong monitoring process that engages people in open dialogue centred around the actions that must be taken to be successful.

Strategic planning is an important part of every organization’s success. There are key elements that must go into strategic planning; if you do not have all the elements to start with, then you must start with the basic strategic planning process (BSP). Everything that you do as an organization will come from your strategic plan. This includes enhanced sales, improved business processes, inventory controls, or market advancement. The list of options is huge. We don’t plan to fail, we just fail to plan.

Don’t forget to leave your comments below.

How to BUSINESS Analyze Stakeholder Requirements

Written by Marcos Ferrer on September 3, 2013. Posted in Articles.

Many BAs ask me where to get the business requirements when no one has done Enterprise Analysis or even a simple “Business Knead”. “That stuff is above my pay grade”, they say, “and even if it weren’t nobody gives us enough time or information about what is really going on. We barely have time to clean up today’s mess, never mind tomorrow’s.”

“Me three” is my reply. My experience and certification don’t change basic human nature. Even when I am invited to high-level meetings, no one thinks of me as a “business owner” or manager. The checks are written above my head, and many command structures still insist on top down flow only.

Stick with us (thanks to my anonymous class, who inspired months of blogs) as we transcend BABOK by explaining how (and why) to get something from nothing , and in the process raise your pay grade*.

Last month we tried to use ordinary analysis to break down stakeholder requirements driven by the need to cut costs, resulting in something like:

1. Internal Service Costs

Total Costs of Internal Service by Organizational Structure
1. Costs by Service Provider Department
  1. Costs by Service Provider Team
    1. Costs by Service Provider (???time/effort)
    2. ???Other incidental costs (overhead/supplies)
  2. ???
2. ???Costs by Service Recipient Department
  1. ???Costs by Service Recipient Team
    1. ???Costs by Service Recipient (time/effort)
    2. ???Other incidental costs (overhead/supplies)
  2. ???
3. Costs by Service Type
  1. ??? On boarding
  2. ??? Annual Training
  3. ??? IT Help Desk
  4. ??? HR Guidance
  5. ??? More…
4. Costs by Chances to Save Resources
  1. ???
  2. ???
5. More ???Cost Views…
  1. ???
  2. ???

2. ???Internal Service Benefits

???Etc.
???Left as an exercise for the reader, similar to above yet different.

I was so tempted to expand this list of trees**, but I decided to take a peek at the forest instead. Why?

Although we have tried to expand the original stakeholder requirement, it is still unclear what is or isn’t a priority. The focus so far seems to be on WHO DID WHAT. The BABOK says that BAs have general business knowledge. What do you know about measuring or enhancing employee performance? What are the impacts of singling persons or departments out? Short term? Long term?

It is not clear how knowing how much internal service is being done by whom for where will change costs or improve the business. At best we could decide to re-train (or fire) the lowest performers, and we will discover that (by definition) there aren’t many of those, and once fired, someone else will take their place. There might be a few VERY high performers, but they will not be reproducible as a general rule.

How many Michelangelos does it take to screw in a light bulb? How many non-Michelangelos does it take to paint a masterpiece? It is quite likely that most employees are doing the best they can in the circumstances, with statistical fluctuations over time, but no significant performance differences.

Blaming (even identifying) the workers to reduce costs is an organizational dead end. Many great leaders reject the use of the “Theory X” approach” (workers are lazy thieves who are best motivated by whippings and emotional abuse). These include Robert Townsend of Avis (“Up the Organization” remains relevant to this day), Douglas McGregor of MIT, and especially Edward Deming (“brought to you by the nice people who made your nice car that you can rely on”) among MANY other quality triumphs. Deming showed that in most cases job performance is randomly distributed among employees over time, once inputs, policies and tools are established.

Another high-level concept worth knowing is that the tyranny of numbers is a risk in any project (“Hey, we are paying $10 per bug found!”). Cutting costs is not a business goal by itself. If it were, the best approach would be to cease operations entirely, achieving zero costs. Finance mavens will recognize that investing zero has “opportunity costs”, and there is no way out – figure out how best to use resources, or stick them in your mattress to rot.

This makes us realize that the stakeholder requirements are not remotely robust or useful as imagined. They represent a literal attempt to monitor internal service costs, perhaps in an attempt to “be fair” and “spread the pain”, with no clue how these costs relate to the business success.

If we pursue such requirements, we are likely to create a system to track internal service costs that has little or no impact on the quality of decision-making. Worse, it might have too much impact on the quantity of decision-making (“look, department D is giving too much internal service this month, let’s dock their pay to re-motivate them to reduce the service”).

SO, what is the real business need? Cost control obviously matters, but how does that “high level abstract not quite a requirement as stated” relate to possible actual requirements? Let’s use a “MOST” analysis (Missions, Objectives, Strategies, Tactics) and see if it helps:

Let’s agree (for this blog) that many organizations have “high-level” missions that are a little “generic”; something like:

Be Customer Driven
Make Quality Everyone’s Business
Practice Respect For All
Maximize Efficiency, Effectiveness and Profitability

This may seem fluffy and devoid of substance (it is** :)), but we can use it as a starting point to re-imagine the stakeholder requirements. It would seem that the mission to “Maximize Efficiency” is the primary mission in play. Leaving out “Profitability” is the easy to commit error. When I trace to this level some PMs (not you, not you, resemblance to real people is a coincidence) tell me “everyone already knows that, don’t waste your time.” In spite of any resistance, no one can forbid me to know the organization mission, and use the knowledge to add value to stakeholders.

This seems like pure “Root Cause” business need stuff. Root cause stuff can be sensitive to discuss, and requires tremendous diplomacy, facilitation and values (don’t blame people) to do well. That is a different essay for some other day. In an attempt to work with this group of “internal service” stakeholders we will pretend to analyze the reasons that internal service is TOO costly:Click image to view larger.

OOPS! Depending on the actual root cause analysis (mine is made up for the blog, can you spot the big error?) cutting internal services might hurt effectiveness and profitability.

What would you do? Don’t hold back, the future of the organization will be impacted one way or another.

Hmmm…is the problem the root cause analysis, or is there a deeper problem? What is the root cause of this rather un-useful root cause analysis? WHO CAN OFFER AN ANSWER? Will James marry Oneida or stay in Paraguay? Is anybody out there?

Have fun!

* Pay grade ≠ pay amount – negotiation is a key competency and worth a try :).

** Not ! 🙂

*** A higher quality mission statement might be “Balance efficiency, effectiveness and profitability”. Maximizing everything sounds good (and seems simple) yet is just as hard as “Balancing”. The word “Balancing” does not hide the deeper truth that tradeoffs are usually necessary and too much simplicity can mislead.

Don’t forget to leave your comments below.