Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence

TURNING OPERATIONAL KNOWLEDGE & COMPLIANCE INTO A COMPETITIVE EDGE

We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

Posts Tagged ‘strategy’

Why Your IT Project May Be Riskier Than You Think

Several comments on a must-read HBR article for an organization considering any IT project of significant size …. Why Your IT Project May Be Riskier Than You Think by Bent Flyvbjerg and Alexander Budzier  Harvard Business Review – September, 2011 http://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think/ar/1 I found several points in this article particularly insightful:   1. “As global companies become even more reliant on analytics and data to drive good decision making, periodic overhauls of their technology systems are inevitable. But the risks involved can be profound, and avoiding them requires top managers’ careful attention.”   >>I’m afraid the large majority of IT professionals don’t really get this … even if they say they do. Prevalent IT requirements methodologies don’t address it well at all. It’s essential that the approach a company takes involves business people to develop business solutions based on business goals before creating system designs. There’s a business problem first, then and only then a technology problem.   2. “Insufficient procedures for financial reporting and internal controls …” >>We see this time and time again as IT designers create very ‘open’ designs that are not based on a common set of business concepts and do not embed a common business perspective. The inevitable result — “revenue leakage” … and as this article points out, much worse. Again, there’s a business problem first, then and only then a system problem. 3. “When we broke down the [IT] projects’ cost overruns, what we found surprised us. The average overrun was 27%—but that figure masks a far more alarming one. Graphing the projects’ budget overruns reveals a “fat tail”—a large number of gigantic overages. Fully one in six of the projects we studied was a black swan, with a cost overrun of 200%, on average, and a schedule overrun of almost 70%. [Only one in six? I think that figure is too low!] This highlights the true pitfall of IT change initiatives: It’s not that they’re particularly prone to high cost overruns on average … It’s that an unusually large proportion of them incur massive overages … By focusing on averages instead of the more damaging outliers, most managers and consultants have been missing the real problem. ” >>The point is simply that IT ‘change initiatives’ are risky propositions, and need to be addressed with … what else … upfront business strategy. That’s what we call a Policy Charter, and we’ve been guiding organizations through its creation for more than a decade. Doesn’t take that long … if you have the right people and the right motivation. Skip it … and pay the consequences!

Continue Reading

HarvardBiz and Use Cases?!? Yes, Seriously … And Seriously Misguided!

HarvardBiz  The Case for Starting a Design Revolution http://s.hbr.org/nXsdOk
 
This article is fundamentally misguided. I’m surprised to find such an article associated with HBR. Use cases are about designing systems, not developing business solutions for business problems.
 
All change initiatives should start with a clear, structured view of business goals and business risks, and what business policies and business tactics will best solve the business business problem. I’m talking, of course, about business strategy. That’s the conversation that business leads want to have. Get them engaged in a discussion of system interaction and GUIs and you’ll inevitably miss the big picture.
 
What if your business *is* about eCommerce? No matter, you still need thought first given to business strategy — the goals, risks and policies needed for a winning business solution. Good requirements will flow naturally from that base. This have always been a notoriously weak area of IT requirements methodologies. Just don’t believe IT professionals who say use cases will solve your business problems. Design attractive systems, yes (done correctly). Guarantee business success? You’re counting on nothing more than good luck.

Continue Reading 5 Comments

The ‘Up’ Why and the ‘Down’ Why

I had a major case of deja vu reading a recent post by Tom Graves, “The Two Kinds of Why”, at  http://bit.ly/qgJ40i #baot. I’ll tell you why in a second. Believe it or not it has to do with our business card. Zachman and I have had a continung conversation over many years about business rules and the Zachman Framework. We’ve moved forward inch by inch. You have to admire a man who is 76 years old and never tires of listening and learning. I certainly do. John has a version 3.0 of the Framework coming out very soon if not already. I can pretty much guarantee you won’t see business rules in the ‘why’ column. Graves says, “One side of Why creates a question: literally, it starts a ’quest’. For most of us, that’s the exciting bit. The other side of Why is the answer to the question, the end of the quest. That was the question, here’s the answer: The Decision. End of story.” Oh not so! Strategy should be viewed as a continuous feedback loop. You put some stakes in the ground, the ‘down’ why’, but you continuously test those ‘decisions’ to see if they hold up in the light of day. Do they achieve what the ‘up’ why (the ‘quest’) set off to achieve? We believe a conversation about strategy (both the ‘up’ why and the ‘down’ why) is exactly the one business leads are looking to have.  Our deliverable for that,  called a Policy Charter, addresses both questions, two sides of the same coin.
  • Looking down from business goals.  What are the best business tactics and business policies to achieve the business goals, and how are the associated business risks addressed?
  • Looking up toward business goals.  What is the business motivation for each of the business tactics and business policies, and why are they appropriate? 
We’ve looked at the world like this since 1996 and it’s proven highly productive in many scores of engagements. I submit to you as evidence Exhibit A below, our original business card from 1996. (I always liked it … I designed it. Obviously, I shouldn’t give up the day job!) See the intertwined why’s? Hard to miss. Finally, business rules are boring?! Not! See  http://goo.gl/0tLD3    

Continue Reading 2 Comments

Business Capability … You Have to Know in Order to Do

As many of you are aware, the Business Rules Forum Conference is now one of three conferences in the annual Building Business Capabilities (BBC) Conference (http://www.buildingbusinesscapability.com/), which includes the Business Analysis Forum, the official conference of the IIBA. So Gladys and I have had to do some hard thinking about the meaning of “business capability”. Here’s our take emphasizing business … A business capability is not an application system, database, set of use cases, enterprise architecture, or any other IT artifact. Its design and implementation might depend on some or all of those things, but that’s a different matter.  Instead, a business capability is created as a business solution to an operational business problem. That solution and the problem it addresses have a scope (definite boundaries) that can be identified in terms of what business items make it up. The business solution is initially developed and expressed as a business strategy (a Policy Charter in our methodology, Proteus).  The business model you create in business analysis is the business architecture for the business capability, a blueprint enabling business people and Business Analysts to engage in a business discussion about what needs to be created, managed, operated, changed, and discontinued. Developing a business solution using a business model does not necessarily imply software development, but if software development does ensue (and it usually does), the business model provides a solid grounding.  Our definition of business capability comes down to this: What the business must know and be able to do to execute business strategy. The part that many people miss is what the business needs to know. Quite simply: How can you really ‘do’ without knowing what your business rules are?

Continue Reading