When thinking about or being tasked with capturing a customer’s detailed requirements, beyond the high-level Business requirements … for me, it’s hard not to immediately draw mental pictures of that well referenced tree swing analogy. For those not familiar with the analogy it simply points out that without proper requirement definition a customer looking for a tree swing could have any of the swings in the illustration delivered to them.
Purposely jumping off the tree swing for a moment… and focusing on software solution marketplace with its vast product range with a plethora of configurations, outcomes and customer experiences, it has never been more important to queue up those powerhouse discovery questions to ensure that you have accurately and clearly understood both the functional and non-functional requirements of your customer. If we do this we avoid delivering the wrong outcome for the client.
A functional requirement typically describes the behaviour (such as automated workflow) or presentation of a configured component that meets the specific needs of the customer, whereas a non-functional requirement describes the systems operation… such as a Web Servers Availability etc.
My Top DO’s and DON’T on Producing Great Requirements Documents
|DO||Have a sound understanding of the customers high-level Business Requirements prior to meeting with them to perform the deeper dive discovery.|
|DON’T||Ask a series of unnecessary/repetitive questions where the information has already been provided in advance. This opens your ‘incompetence account’ with the customer and doesn’t build the necessary rapport or credibility for downstream engagements which are required to deliver success.|
|DO||Schedule a Discovery Session with all applicable stakeholders, communicating in advance a structured approach with an agenda or at a minimum a simple email to highlight discussion points for the Discovery session.|
|DON’T||Avoid the inclusion of the IT Manager and/or Senior IT Representative in your Discovery session.|
|DO||Use the phone wherever possible to help qualify any gaps in understanding of the customer’s requirements. Verbal communications result in far fewer misinterpretations of conveyed information over those which can occur in a series of detailed emails.|
|DON’T||Fill the Requirements document with verbose, non-specific or redundant content (e.g. marketing content) that doesn’t help define or qualify the customers’ requirements for review and approval.|
|DO||Use a very good healthy balance of quality images, screenshots and diagrams to present your clean understanding of the customer requirements in your proposed technology. Microsoft Visio is my go to application of choice.|
|DON’T||Make wild and nonsensical assumptions, when they can be solved with a short call or a qualifying email.|
|DO||Document the specific non-functional requirements for success even if they are requirements for the client to deliver on. IE IT landscape changes needed, additional staff training needed etc|
|DO||Scale the length and depth of Requirements detail with respect to the level of complexity of the solution delivered. See Solution Complexity to Requirement Detail Chart below.|
Using the Correct Weight Approach
Following on from my last ‘DO’ recommendation, Requirement documents should contain the appropriate weight of detail/content to be classed as an ‘efficient document’. Obviously producing an overly wordy document for a small, yet simple project can frustrate many customers as they struggle to digest all of the details. On the flip side unconsciously leaving a lot of important detail out OR left only to verbal references will effectively leave the gate WIDE open for assumptions to be made on all sides. Poorer outcomes are consistently achieved when this lack of detail and specification exists within the documentation.
Solution Complexity to Requirement Detail Chart
Hopefully some of these quick tips will help you produce superior requirements documents for your projects.
Professional Services Director
The Ellby Group (FileBound Australia Pty Ltd and Upflow Pty Ltd)
Our organisation spends a lot of time assisting others to implement Document and Work Management solutions. We have been doing this since 2007 and individually many of us have been doing this for a lot longer with other organisations. We are still surprised at organisational avoidance of implementing change management processes for their teams.
Many years ago systems projects had a very strong technical leaning. Remember using the Software Development Lifecycle (SDLC) to structure long projects to deliver positive organisational outcomes? Projects these days happen a lot quicker (generalisation inserted – we would love your view). This speed is underpinned by advances in technology as well as globalisation driving a world market. We can now configure software to do a lot of things that we used to require software development projects to deliver.
What are the impacts of this faster delivery of organisational outcomes? Here are The Big Four impacts we see;
1. Less structure.
We do not see organisations using Project Managers (PM) and Project Management hygiene as frequently as they used to. This provides less organisational structure which leads to generally poorer outcomes. In our experience having a PM on a project virtually guarantees the project will not fail as well as ensuring the project will deliver at an acceptable time and cost (note the use of acceptable as opposed to budgeted, that could be a single blog in its own right). As a minimum, organisations need to have a responsible executive so that there is a single point of escalation for the technical resources on the project. We would love to see this trend away from formal PM reversed.
2. Less formal requirements.
A significant trend we see is the reduced focus on formal requirements. We often see projects being attempted with no agreed formal requirements. The theory being that the tools can be adjusted so easily that once a solution is live it can be altered as needed. Whilst this may be somewhat true, it does not deal with the various pre-conceived expectations of the stakeholders. Stakeholders are quick to get frustrated and unsupportive of the project if their early expectations are not met. One of the great things about a formal requirements document is the articulation of expectations before any delivery has happened. If there is a gap in the expectations of the solutions delivery team and any of the stakeholders it is highlighted and dealt with long before the project is thrown seriously off track.
3. Lack of a formal change control process
Just having an initial set of requirements is not sufficient. We see projects falter regularly because valid changes to the project are not managed with a controlled process. The beauty of a change control process is the involvement of all stakeholders and management of their expectations throughout the delivery. As with formal requirements, change controls are a vital commercial and legal instrument that can reduce your organisational risks.
4. People aren’t ready
With modern technology we can often implement a really complex solution to an organisational problem in a very small amount of time. Whilst this is great and any technocrats will love the speed and outcome, it give technophobes very little time to adapt to a new work design. We see this happen a lot and often those technophobes will start an internal marketing campaign against the project / changes (interestingly in our experience once the key issues of this group are addressed they can be turned into strong advocates). In our experience the number one reason why projects struggle is the human change element. Of course there is a direct link between this impact and the project management impact described above. Less Project Management hygiene leads to less focus on the core change management principles built into that hygiene. We would encourage anyone currently implementing or considering a technical change project to spend more time considering the human change elements. If you do you will be rewarded for having done so.
Of course there are other factors that can lead to implementation issues – poor technology choice, poor partner choice, external factors, poor resourcing and inadequate skills to name a few. Despite these other risk factors we still see most troubled projects having one or more of The Big Four issues identified above as the root cause of the challenges.
In summary, we suggest that all solution implementation projects have a Project Manager, use a tight requirements recording and change control recording process as well as have a program of change management built into the core deliverables. Implementing hygiene’s to account for The Big Four will seriously improve your chance of implementation success.
Document Management has come a long way since Edwin Siebel invented the filing cabinet in the 1800’s. It has to be said however that innovation in the Document Management space was pretty slow up until the advent of Electronic Document Management Systems (EDMS) in the 1980’s.
EDMS was brilliant because it immediately improved accessibility of the stored documents as well as the timeliness of that access. As the EDMS vendors continued to innovate they introduced innovative functions such as version control, document locking, annotations and even electronic forms. At the time this was all very forward thinking and really started to empower organisations and their users.
Move forward to the last 5 years and there has been a lot of the noise in Document Management around the addition of workflow capabilities to Document Management platforms. This is a match made in heaven as documents are at the core of most organisational processes. It is a great way of getting an ROI on what was once often considered a cost liability. I think all the major players in the EDMS pace are now adding workflow (office automation, work management, business process management etc.) functionality to their core offerings (some more successfully than others).
So what of the future? Where does Document Management go next? Well here are some of our thoughts at FileBound Australia;
1. Process Tuning
Implementing document based workflows (as mentioned above) has been a tremendous leap forward for organisations. The next logical step to that is having the ability to performance tune these workflows. To do this organisations will need to analyse the data created whilst running the processes and look for improvement opportunities. This will require EDMS vendors to build analytics capabilities into their platforms. Once this step is taken we could even see the emergence of self-improving workflows where the analytics engine makes assessments and adjusts the work process automatically.
2. Explosion of the electronic form
Essentially e-form engines allow organisations to easily create standard forms and letters. These documents are the lifeblood of an organisation and represent a significant administrative load (and therefore cost) to all organisations. Some of the EMDS platforms already deal with e-forms however we believe their use will multiply as more and more processes are automated. This is due to the fact that e-forms can be used to trigger workflows or created as a critical component of a workflow. Future EDMS development will revolve around e-form design engines and hosting platforms so that any organisations staff, customers and suppliers can access and use the forms.
Investment in mobility will continue unabated. BYOD programs will continue to proliferate and fuel the need for EDMS system to work with multiple mobile platforms. The mobile platforms have historically been lesser functioned to the core EDMS function and over time this will change so that users can have a richer experience whilst on the move.
EDMS vendors have been slow off the mark with Cloud. Most of the EDMS vendors have a client-server legacy and trying to cloud enable that has proven expensive and difficult. The growth of cloud-native vendors and the changed appetite for Cloud from the buying market will see Cloud delivered EDMS start to and continue to grow aggressively. One of the biggest influencers in future growth will be the SME market. Cloud represents an ability for these organisations to access valuable functionality that has traditionally only been afforded by larger organisations. Small organisations will start to manage their documents and workflows in ways that are similar to larger organisations.
5. Vendor specialisation
AS EDMS platforms have evolved many of them have tried to be all things to all people. We see tenders in market looking for requirements that span Capture, DMS, Web Content Management, Digital Asset Management, Case Management, Records Management, Knowledge Management, Analytics, Asset Management and Workflow. Now as we move forward each key vendor will need to determine which of these functions are their core strength. It is not feasible that a vendor will be able to tick all those boxes and even if they did it is unlikely that they would deliver quality outcomes. Vendors will need to know what they are good at and the market will need to be better at assessing which of these functions are their priorities for investment.
6. Capture integration
We have already seen some mergers and acquisitions where Capture Vendors buy EDMS assets and visa versa. Going forward these two groups will continue to merge, partner and tightly integrate. EDMS players will continue to build capture capabilities into their platform and offer capture capabilities as part of their workflow processing. These capture capabilities combined with the e-forms engine will allow the document to morph into a container of data that can take many shapes and forms as it moves through its work processes.
These are just some of the trends we see going forward. We would love to know your thoughts so jump in below.