“The more clearly you understand the problem, the more effectively you can design the solution.”
John Zachman
Over the past five decades, I’ve observed that very few businesses have a comprehensive and clear understanding of their operations. This often leads to misalignment in crucial elements like job descriptions, workflows, key performance indicators, and business requirements for technology. Too often, these are created just to “tick a box.” Having such a thorough understanding of a business is challenging, and it becomes even more difficult to maintain as the business evolves. In the finance world, all financial artifacts are based on the Chart of Accounts. At SlightlySkew, we refer to this operational framework as the Chart of Works – a complete representation of the business’s non-financial artifacts. While documenting this in text form is nearly impossible, SlightlySkew leverages Information Engineering national models to provide this full, integrated view, ensuring every part of the business aligns with its overall capabilities.
Businesses without a Chart of Works tend to skimp on business requirements when they do software development or purchasing a software package? I would imagine that some of the reasons could be:
- Perceived Time and Cost Savings: Some businesses mistakenly believe that by rushing through the requirements phase, especially without a Chart of Works, they can save time and money upfront.
- Budget Constraints: When budgets are tight, companies may cut corners on the planning and requirements phase, viewing it as an area where they can reduce immediate expenses.
- Underestimating Complexity: Some stakeholders may not fully grasp the complexity of software development or aligning the business with the purchased software package and the critical role that well-defined requirements play.
- Market Pressures: In fast-moving industries, there’s often intense pressure to get a product to market quickly.
- Operating as “Agile”: Many businesses adopted the so-called “Agile” framework to software development and this is often misinterpreted as a minimum documentation approach and so, requirements are very poorly defined and seldom documented.
The temptation to skimp on business requirements may stem from a desire to save time or money, the reality is that this approach mostly leads to greater costs and risks down the line:
- The Cost of Rework: The costs of rework often aren’t visible until later in the project, making it easy for decision-makers to overlook them when skimping on requirements. The true cost only becomes apparent when projects run over budget, miss deadlines, or fail to meet stakeholder expectations.
- Opportunity Costs: Rework not only incurs direct costs but also leads to missed opportunities. Delays in delivering software can result in lost market share, reduced customer satisfaction, and the inability to capitalize on business opportunities.
- Project Delays: Without good business requirements the chances of scope creep, and project delays are huge.
In the world of business, clarity is the compass, and direction is everything. When it comes to requirements, just checking boxes is not an option with SlightlySkew – we’re defining the roadmap for success. And that’s why we stand by principles that are as unshakable as they are essential. The Institute of Electrical and Electronics Engineers (IEEE 29148-2011) and the International Institute of Business Analysis both tell us what’s needed, but here’s how SlightlySkew lives it:
- Requirements at same level of complexity: The hierarchical structure of the Chart of Works ensure that requirements, regardless of the requirement notation selected, will be at the same level of complexity and priority.
- Clear: If it’s not clear, it’s not useful. Requirements should be so straightforward that they cut through the noise like a sharp knife, leaving no room for confusion.
- Complete: Every piece of the puzzle must be there. A requirement with missing elements is like a recipe without the main ingredient – it just doesn’t work.
- Correct: This isn’t just about getting it right; it’s about aligning with the true needs of those who matter – our stakeholders.
- Consistent: A symphony, not a cacophony. Requirements must harmonise with one another, with no conflicts to derail the project.
- Feasible: If it can’t be done, it shouldn’t be on the list. We only commit to what’s achievable within our resources and constraints.
- Testable: The proof is in the pudding. If we can’t measure it, we can’t guarantee it, and that’s non-negotiable.
- Traceable: Every requirement should have a breadcrumb trail that leads back to its origin, ensuring that nothing gets lost in the shuffle.
So, how do SlightlySkew make this happen?
At SlightlySkew, we don’t just follow the framework – we use it as our foundation. The Zachman Framework isn’t just a tool; it’s our blueprint for precision. Whether we’re building something from scratch or integrating a new solution, this framework ensures that every requirement meets our high standards, every time.
We start by organising the chaos. The Zachman Framework lets us break down the business into layers, from the big picture to the day-to-day operations. And here’s where it gets interesting – we use the “What” or “Work” column to drive everything. This isn’t just a list of tasks; it’s a deep dive into how your business functions, step by step, ensuring nothing gets overlooked.
Think of it like functional decomposition, but instead of just analysing, we’re creating a roadmap. Each layer of this roadmap gets us closer to a complete, holistic view of your business. We ask the right questions: Who’s doing the work? What information flows in and out? When and where is it happening? Why does it matter? And how do we measure success? By answering these, we ensure that every part of your business aligns with the whole.
This isn’t just about automation; it’s about clarity. With a clear, correct, and complete description of your business, you can do more than automate – you can optimise. Whether it’s crafting precise job descriptions, streamlining operations, or boosting efficiency, the benefits are endless.
Once we’ve painted this picture, extracting business processes becomes second nature. Whether through data flow diagrams, use cases, or user stories, everything we deliver aligns with the attributes of solid business requirements.
At SlightlySkew, we follow a process that mirrors the best practices of the International Institute of Business Analysis:
- Requirements Elicitation: We dig deep to understand what you need, using techniques that range from interviews to observations, leaving no stone unturned.
- Requirements Analysis: We analyse what we’ve gathered, ensuring it’s complete, feasible, and aligned with your goals.
- Requirements Specification: We document everything in a way that’s not just clear, but actionable – ready for design, development, and validation.
- Requirements Validation: We verify and validate every requirement, making sure it’s not just correct, but perfectly aligned with your needs.
- Requirements Management: We keep everything on track, managing changes, tracking progress, and maintaining traceability throughout the project lifecycle.
That’s how we do it at SlightlySkew. Not just by the book, but by the blueprint – crafted with precision, executed with passion. Because in the end, it’s not just about meeting requirements; it’s about becoming extraordinary.