"A great start is half the work" - Well that might not be entirely true, setting off on the wrong direction most certainly will be double the work, if not more. So what is a great start when considering implementing new software? Unless you are in the business applications industry, you do this type of work only once in a few years (for some organisations, once in a decade). The following are three simple to use tips, that nobody from the industry has told you. Tips that increase your success and significantly decrease your spend on business applications.
1. What is the most important question
I used to think that "Why" was the most important question to ask. I was wrong. So, what is the most important question? Exactly - what is the most important question! It starts with: "what do we do" - what is the purpose of our business, and what does that mean to our customers. This gives a high level outcome. For example: "our purpose is to provide our clients with....". Then break it down: "what are the capabilities we need to serve that purpose?" - for example (and these are very generic): purchasing, manufacturing, storing, selling, invoicing, managing accounts... Most companies will have these generic capabilities, but the smart ones among us will add some distinctive (if not disruptive) components to it - such as (example) educate our customers, educate the community, connect supply and demand of <...> services as a "man in the middle". For example - AirBnB may have a disruptive business model - but the capabilities for the large part follow the same as everyone else - i.e. acquire customers, sell, invoice, etc. There are a few unique (or disruptive) capabilities in this mix that make the model interesting.
And herein lies a nuance on the "what" question: what can we do different that is a profitable disruption within our market? Whatever answer comes out, there is opportunity to investigate - after all - if you implement a new business application just to maintain status quo, it seems a rather lot of money and effort for not changing. We need to ask the opposite as well- or, deal with our confirmation bias. Especially when it comes to novel and potentially disruptive ideas, we tend to get overly enthusiastic and forget that it might not work out as planned. The two essential questions to ask are: "What are the potentials or possibilities that our strategy may not have the desired results" and "what are the worst case and most likely case consequences if that should occur".
Finally, these capabilities need to be made into something concrete - "What is be done to execute this capability?" - Write this as a form of a story - "As a user, I need to be able to....." and follow up the question with answering "to what end?" - i.e. "in order to.... ".
2. Not all features are created equally
Whenever I would go into an implementation project, and the customer says - "all requirements are must haves, we have culled everything else", my first instinct was "RUN!" - but, that is not an acceptable alternative. The truth is, not everything is required, and not everything is equally valuable. The questions mentioned in the above paragraph leads to a feature set - some of these may indeed be required, others may simply be nice to have. How to go about assessing what is what, and which is which? Ask a follow up question: "what happens if we do not have this feature?" and "what is another way of preventing that consequence?".
Features fall into the MoSCoW categories (Must have, Should have, Could have, and Won't have this time). I have written about this in other articles, but here is a brief reminder - Must have = business standstill/process halt if not in place, Should have = tangible and measurable benefit, Could have = minor benefit, perceived benefit enabling adoption, and Won't have this time = maybe next time, but not considered now.
Within the MoSCoW categories, each feature represents a value. Ideally, the value is quantified, but at minimum, there is a relative value statement. Stack rank each feature in the Capability/MoSCoW matrix - most valuable on top. Remember: 80% of the value resides in 20% of the features! Like a sound-engineer producing a new album, all instruments, frequencies, and compressions are added or removed based on the value they add or subtract from the overall sound.
3. Bring it together with a system
Having the capabilities and feature values makes sense if they are relatable - A tip to do this is via an Agile implementation collaboration tool, such as Zoho Sprints (you could use a spreadsheet - but that is a lot more difficult to control and maintain) - use the "Epic" as a representation of the capability, and the required feature (as represented as a user story) as a backlog item (of the type story). Features are associated with each epic, and each feature has a MoSCoW classification, as well as a Value Stack Rank assigned. Therefore it is easy to see at a glance how a feature is going to impact the overall ability of the organisation to fulfill a capability.
In summary
- Business applications exist to help fulfill a capability
- Most capabilities are standard across all businesses, with only one or two capabilities making your business unique or disruptive
- Ask "what" - "what needs to be done", "to what end", "what happens if it is not done", and "what can we do to prevent negative consequences if it is not done"
- Assign value to the features that come out of the "what" questions
- Don't be afraid to change some capabilities, or features - you did not implement a new system to keep doing exactly the same things the same way
- Use a collaborative tool to keep track of the capabilities and associated features
If you want assistance, we can help with facilitation of workshops, help you build your capabilities map and assess the feature/value matrix.