From Vision to Reality - Doing it Right

For those of us in IT, we will know that building 'effective' systems is really all about getting the requirements right. If we know what the clients needs, then we can build something to fulfill those needs. Simple, .. right ?

Running Blind

Well , quite often , and especially when a technology has been around long enough for everyone to understand their general working , I've seen a bee-line by business owners, BAs, and tech leads, and solution architects alike, straight to defining the various technical build items.

There is this assumption, that 'everyone' knows what ''we need to build & why, we have this tech, let's just start the build''.

This is exacerbated by an over-enthusiastic reliance on the agile method for iterative delivery and leads to tension to 'get the project started as soon as possible'- we'll course correct on the way anyway.

While this may work for established delivery trains, it can wreak havoc when applied to the starting of major new programs.Scrum teams can go on burning points, producing a good burn down chart, but not necessarily delivering a usable product, simply because the time wasn't taken in the beginning to establish a vision and a set of business objective to drive strategy and the requirements.

Working your way down

In any situation, any tech build can and should be traced back to a functional requirement which then should be tied to a business objective. The objective should ultimately be aligned with an overarching vision.

Thus the key to ensuring any tech build is fit-for-purpose is to establish ( or align to an existing ) vision and working out key objectives and requirements from there.

i.e

• Vision - what the program / project / line-of-business / company aims to become or establish
• Business Objectives - The business outcomes that are critical in realising that vision. Each objective may have several business requirements underneath
• Functional Requirements - The expected functionality out of the finished solution that will help the business meet their objective
• Technical Requirements - The technical capability of the finished solution that will deliver the required functionality

Such a structure gives excellent trace-ability and ensures that whatever is being built is aligned to real needs. The following is a rule of thumb that I've seen repeated regardless of domain or tech. The numbers can vary , but the overall ratio has remained more-or-less the same.

Vision > 4 - 8 Business Objectives > 15- 20 Functional Requirements > 25 - 45 Technical requirements

Note: It's important to remember not to boil the ocean. It's ok to start small and iterate, but do note that changes in requirements or objective will have an impact on scope and build as well.

Sample Structure from Digital Experience and Content Management

The below is a sample structure for the above aligned to a digital experience and content management solution. In this Functional Requirements has been replaced by Content Strategy

Note:

1. While this is a sample representation , it covers key elements for a DCXM program
2. The number of items increase as one goes down the diagram
3. Each item may have several considerations underneath them for the actual detail
4. A solid thick line connecting Vision -> Objectives -> Content Strategy-> Technical Requirements - that is how things should be driven.
5. Remember to keep it straightforward

Here are some notes on the points above to illustrate some detail.

Vision: e.g. To gain market leadership across a set of services

Business Objectives

1. Faster time to market : To be able to roll out changes faster , more cheaply , thus facilitating a test and learn approach
2. Reduces risk : Reduce or eliminate compliance related issues associated with our operational business
3. Effective User Engagement: Engage both B2C and B2B , provide a white-labelling capability and allow for a two-way conversation with our consumers
4. Lower TCO : By way of reduced cost of support and liecnses

Content Strategy ( Functional Requirements for a DCXM platform )

1. Content Modelling : Normalising and standardising content and information across available services. Includes type and format of content
2. Core Process : From content ideation, sourcing, creation, publishing & archival. Includes any consideration of user generated content for ideation ( e.g. through comment )
3. Multi-Lingual Content : If there is a need to consider any content in multiple languages and regions
4. Content Delivery : e.g. through feeds / fragments to digital devices, or native web and if there is a need for variations of content for different contexts and channels
5. Discovery: How the consumer discover the content, including offsite parameters such as search engine and marketing to on-site parameters such as navigation, aggregation , site search
6. Personalisation : e.g. based on demographics, channel or digital behaviour. Also considers aspects for digital data context , analytics , implicit personalisation and explicit personalisation

Technical Requirements

1. Taxonomy : Content sturcture for digital content, digital assets, tags
2. Metadata: Operational, administrative , descriptive metadata across content assets and experiences
3. Ingestion : If content needs to be ingested from external sources
4. Content Assembly: If content needs to be re-combined to produce unique experiences ( follows heavily from content modelling )
5. Templates / Components : The technical containers to author and create content based experiences
6. Downstream Consumption : If any system needs content from the main platform . Typically deals with batch
7. Content Syndication: If content needs to be provided through feeds to other consumers such as digital devices, in real-time and on demand
8. URL Management: Considerations of links authored into the content , especially if the digital platform is not the owner of the experience as is in the case of a headless CMS
9. Content Aggregation : How different content feeds can be aggregated in a single view - typically impacts site search and landing page experiencees
10. Others ( Workflows, Versioning ) are self evident

Keep It Simple & Never Force It

All of the above can look quite involving and ambitious. The most common pushback I've heard is that "I just want to build a simple website" or "I just want to build a simple application"

This is natural and its important not to force anything. If you're in a consulting position , it's your role to help tease out these hidden requirements and discover the true drivers of a project such that an effective course can be charted

Use these objectives to help drive the conversation to reveal a lot of the above. e.g." What will the application do? " Why do we need it " "why is the business sponsoring this and why now"

You will find that the answers to Vision , Objectives and to a degree Functional Requirement are all known and can be very easy to uncover with the right conversation. Some things may not be known but evolving and that's ok too.

At the end of it, both you and your stakeholders will have a much better and richer understanding of what everyone needs to do and why

I hope you all are able to glean useful insights. If you have anything to add or different points of view, put them in the comments below or feel free to message me as well.