If you read the title and thought to yourself, “Hey, Mulvey got it wrong, it’s ‘Measure Twice, Cut Once’” I’ll bet you have had an experience with someone who used the old woodworking term. Woodworkers use it to indicate it’s better to double-check your measurements before you commit to cutting the wood, lest you waste time redoing work (and incurring expense if you have to buy more wood). It’s a great proverb to get you to think about double-checking your work and confirming your measurements. But what I’m talking about is using the measurement as an enterprise asset – once you create the measurement, use that over an over when you are working on different projects.
Consider a recipe you have at home. Every time you make chocolate chip cookies, you pull out the recipe box (or call it up on your iPad – we are in the 21st century after all) and look up the recipe. Chances are you don’t think about trying to figure out how much flour or chocolate chips you need (although personally, I don’t think you can use too many chocolate chips!). You basically use your “tried and true” recipe you have used over the years. There are probably some heirloom recipes you have in your household you pull out every Holiday occasion with family. The point is, you already have the one household recipe (measure once) that you use over and over again (cut twice) to achieve the same results.
So how does this relate to business practices? Well, think of your household as the organization, and the recipe as the enterprise asset. The organization owns the assets, and they are used over and over again. Think of assets such as data, business rules, stakeholders. One project already went through the trouble of analyzing them and figuring out what the enterprise needed. You need to reuse that analysis and link it to another project. If the first project figured out the business rule is, “a high value package one that is $5000 or over”, you don’t need to reanalyze and figure that out again. You merely need to link (or trace) your project to that original business rule, and reuse an enterprise-wide asset. And not only just the project, but applications, interfaces, stakeholders, data, etc. What you have, then, is an enterprise-wide repository of assets.
You might think this takes work. It does. What is the benefit of all this work? Think about a simple linked structure as shown below.
Suppose you’re working on a project in which you are adjusting some of the data fields in the Bill Payment System API (Application Program Interface). You can now trace that back to another system that uses that API in addition to a stakeholder who may be affected by that data. Does your organization experience problems missing stakeholders? Once you have them all linked together with enterprise assets, you can quickly make a determination as to which one of those stakeholders may be impacted by a change in one of those enterprise assets.
Also consider approaching it from another angle – your organization has enterprise-level data (i.e. business rules). Here’s an example from an organization that has a business rule in the enterprise repository. The repository contains the organization’s business governance contained in rules. Each system, process, API, or stakeholder who encounters this rule must enforce it. The organization has gone through the necessary analysis to identify the value that states what a high value package is within the entire enterprise. They have “measured once.”
All of the systems that enforce this business rule are linked to the one place the rule is stored - “cut twice.”
A lot of work went into creating these linkages, and here’s where it pays off. It is far faster to link to something previously defined and verify an impact is acceptable than it is to redefine it every time you do something. BA’s are constantly blamed for spending time asking questions of stakeholders where they already know, or should know, the answer. Verifying and analyzing impact and change is far faster and people see why this is important – recreating the wheel each time.
Ready for another big impact? Here it comes…architects, project managers, and executives all dream of the day that analysts could roll up a report that states, “these are all the projects that are hitting this one system, or are impacted by a feature delay, or are hitting a stakeholder group all at once, or were delivered last year” to benefit your Senior Vice President (SVP). But people have a brutal time being able to develop this information because they don’t measure once, and cut twice. They don’t define enterprise objects in a repository and use tools to create links which report impacts and capture expected issues.
Suppose your organization was making a decision to change the value of the high value package? Now you have your impact analysis and just by looking at the systems traced to it, you can determine the impact of the change. In this example, 6 systems and 2 APIs would have to make a change to their systems if the amount of the package was changed. You can make far more effective decisions when you know the impact. You can estimate better because you know the impact. Additionally, you can better plan your rollout since you can understand which systems can roll out by which dates. And (yes, there’s more) you can look at all of the impacts and prioritize against which systems need to make the change first, second, etc. if there are resource constraints.
Want more benefits? You may find you have systems enforcing duplicate business rules. One system may have a rule analyzed as Greater than $5000 and another as Greater Than/Equal To $5000. Different systems have analyzed the rule differently and are enforcing it differently. Of course, if that rule had some context like, Who created it, who is the owner and why is it here, you might realize it was a recent change impacting a subset of accounts instituted by the compliance officer. By linking to an already-created rule (or an already-created asset), you avoid recreating it (“re-measuring”) and instead enforce what was already analyzed. Additionally, when analysis is done independently in each of these projects, you have disparate enforcement. One system may have made the change and allows the package in but another system downstream will fail because it has not had the change put in. This puts the entire process at risk.
So how do you go about putting this into practice? Let’s look at three strategies: Excel, Database, and a Requirements Management Tool.
-
Excel – This is painful. Excel is a great tool for financial calculations, but as an enterprise-wide repository linking enterprise-wide assets together it will cause much pain in your BA camp. The reason is everything is getting tracked manually. Something changes in one person’s area, and you have to update it in yours. Also, there is no good searching tool inside Excel. Additionally, it doesn’t manage relationships very well – it’s essentially a flat-file database when used as a requirements management tool. Yes, you could use it to manage many-to-one relationships with stakeholders, but you would be duplicating information in cells. Trying to manage all of that duplication at an enterprise-wide level would drive someone crazy. Think of the challenges in this situation the same as trying to manage a mid-sized company’s financials on a spreadsheet. Technically, you could do it, but why?
-
Database – now you’re getting into the management of pieces of data and records. A database could be effectively used to manage relationships. You would be able to manage the many-to-one relationships within your organization and could search for information by going in looking for links by stakeholder, data, system, interface, or any other asset you chose to link. Unless a front-end UI is put on top of it, you could have a great back-end database, but a low adoption rate from users unfamiliar on how to find and link records. Linking also becomes manual selecting records and choosing which records in other tables link to them. Your database structure needs to be set up correctly in order to take advantage of how you are linking your items (i.e. One Stakeholder can trace to Many Systems). This is the classic “I can fix this by creating a database and putting a front-end onto it”. You’re now into building your own system on something that’s got to work well across the company. It can work well in one area, but as it moves up to an enterprise level, it starts showing its limitations.
-
Requirements Management Tool – build or buy – your choice. These tools are built to enable linking objects to other objects. These objects are then structured into traceability within the organization. You can then track a project through its lifecycle and its relationship to other enterprise assets. Consider how you can cross-link enterprise assets (shown in red, below) in a requirement management tool.
The enterprise assets can be linked and traced through the project lifecycle. As stakeholders and data get linked into a project and system, those assets then become attached to the new system. When something changes in one of those enterprise assets, the impact can be determined across the entire enterprise.
Sure, there are challenges, and that’s to get the enterprise to adopt this strategy. Also, you want to get a tool they can be comfortable using and interacting with. If it’s too cumbersome, you’re going to lose your audience and it’s going to hurt your adoption. But think about how well you can truly understand your enterprise and the implications of changes.
What does your organization look like, and are you “measuring once and cutting twice?”
Author: Paul Mulvey, Director of Business Analysis, Enfocus Solutions
Paul is the author of Business Analysis for Dummies, a sought-after speaker at conferences and BA development days, and one of the top-25 business analysis influencers on Twitter. His passion is making concepts relevant to the audience. He can be reached at [email protected].