What is it?
Requirements for a project need to be mined, compiled, analysed, negotiated, specified, validated, tracked, and updated during the life of a project. All of this has to take place within a controlled environment so that;
- All stakeholders know exactly what is to be delivered by the project team.
- There is governance placed around the authorising of changing requirements.
- The solution can be supported into the future. i.e. new personnel can read the requirements and get a FULL understanding of the system intent.
- Each requirement can be traced back to a specific commercial outcome.
What can it look like?
The method of requirements delivery will vary from project to project normally based on project complexity. As well as complexity the level or type of requirements management can vary for risk, cost or political purposes. Here are some common project requirement configurations across simple, standard and complex project categories;
Each organisation may use different document titles however the purpose and content should be very similar. Some organisations may also use a version system on each of the documents. The core concept here is that collectively all requirements are trapped and documented.
The Commercial Imperative?
The requirements delivery for a project is directly related to the projects commercial outcomes. Every requirement delivered should exist in one of the requirements documents and each of the requirements should have an associated commercial cost (even if it is $0). A problem we see too often is project teams failing to document $0 changes. Whilst they may think that this is saving time on admin they are actually causing the following potential problems;
- Future support engineers may not be able to understand what was delivered by reviewing the documentation.
- They miss the opportunity to show the client what value add they have delivered [especially if there were multiple “no-charge” changes.
- Having a change made to the deliverable without the appropriate authorities knowledge or approval.
This diagram shows the accumulation of cost [or revenue if you are a service provider] that should attach to the requirements.
What happens when we get it WRONG?
Research tells us that approximately 50% of projects have a frustrated delivery and approximately 25% of projects have a complete failure to deliver. Poor requirements management is a major contributor to both of these outcomes.
Failure to manage requirements can lead to any or all of the following NEGATIVE outcomes;
- Stakeholders feel they have lost control of the project and withdraw support.
- Unneeded requirements can be delivered.
- Critical requirements can be missed.
- Forward support of the solution can be costly and time consuming.
- The project can experience poor commercial outcomes.
- Loss of reputation from delivering a poor outcome.
The good news is that with proper planning and care any organisation can become good at project requirements management. See our other blog posts for additional related information;
At FileBound we would love to hear any thoughts you have around this subject matter. Have we missed anything? Have you noticed similar outcomes?
Chief Executive Officer
IT projects are notorious for having a high rate of partial or total failure. These failures are often born of poor project execution and can lead to any or all of the following outcomes;
- Additional resources needed to deliver the project on time.
- Additional time to deliver the project with the same resources.
- Reduced or modified functionality of the project deliverable.
As well as these troubled outcomes there is also the fatal outcome where nothing gets delivered. This blog seeks educate on the hidden costs of the poor project execution that lead to these outcomes.
Before exploring the hidden costs lets take a look at the real or understood costs. In project terms there is a golden rule relating to remediation (rework) costs. Essentially the cost of remediating a troubled project magnifies exponentially the further into the project you get before identifying the issue. For example:
This table tells us is that if we fail to discover an issue until the project has gone live then we are faced with a cost to remediate that is one hundred times greater than if the issue had been found during design. So lets assume the issue in design cost four project hours to remediate. Using sixty dollars an hour as our cost base then failure to find an issue until a solution is live could cost us $24 000 to correct.
Now those hard costs are a real problem for an organisation, yet these can often seem insignificant next to the hidden costs of poor project execution. Lets explore some of the major hidden costs of these poor project deliveries;
Opportunity cost of the project team resources
In most organisations there is a resource bottleneck in relation to high value IT resources. These resources are rarely idle and generally go from one project to the next as an organisation continues to transform itself or its clients based on the demands of their respective markets. When a project suffers from poor execution it either delays the current project resources moving to a new project or it draws in resources off another project to help with the remediation. In either case there is another of the organisations projects that gets delayed or restrained. It is rare for organisations to factor in the cost of these ‘other project’ delays when assessing the cost of a poor project deliverable.
Opportunity cost of your executives
When a project starts spinning into a troubled state it inevitably drags the organisations executives into it’s wake. These executives are the ones that need to re-organise and reallocate resources. They are also responsible for the additional communications and expectation management around the knock-on impacts of the struggling project. This all takes time and distracts the executives from other tasks. These other tasks could be revenue in nature or could simply be tasks to ensure the efficient operation of the organisation. Either way these knock-on effects can become quite costly and are never assessed as costs associated with the rectification of the troubled project.
Opportunity costs associated with sales misdirection [service provider]
If your company is a third party delivering the project for your client then there are a whole extra level of opportunity costs you need to consider over and above the ones detailed already. The largest of these is the opportunity cost of having your sales arm continue to be involved in a damaged project. If your sales team are engaged in these post sales activities they reduce the amount of pre-sales activities they can perform and as such there is a direct reduction in revenue.
Future revenue cost of reputational damage.
Often a troubled project leads to failed customer promises. These failed promises lead to reputational damage that can impact the organisation to sell its customers products in the future.
Future revenue cost of late delivery
Often an organisation is undertaking a project to enhance a listed product or create a new tailored product for its customers. Delays to these enhancements or delays to the introduction have a direct revenue implications. Notably like the previous hidden costs, these are never taken into account when tallying the costs of poor project execution.
As you can see from the above list there are some very compelling reasons whey we should all place a high premium on getting projects executed correctly the fist time around. Feel free to review the following blogs that deal with the methods for avoiding these poor project outcomes;
At FileBound we would love to hear any thoughts you have around this subject matter. Have we missed anything / Have you noticed similar outcomes?
Chief Executive Officer
As the world continues to change as does the role of the salesperson. In many ways the transformation of the sales team (and its members) is the most important transformation in any organisation for as we all know “nothing happens until someone sells something”. In this blog we will be exploring the traits of the Trusted Advisor and why, now more than ever, they are necessary traits for any professional salesperson.
So what is a Trusted Advisor? Well the name really does present the answer. It is a person who is not only trusted by others but is sought out by others for their advice. The following diagram depicts the Trusted Advisor role in terms of the relationship between personal intent and functional capability (subject matter expertise).
Now we know where a Trusted Advisor sits in the Sales landscape we need to explore the traits that elevate a salesperson to this space. There is plenty of literature on this topic but if I had to distil all that I have learned about the traits of a Trusted Advisor here is the list I would present;
1. A Trusted Advisor has intent for the long term. To do this the Trusted Advisor will seek an understanding of the prospect / customers strategic objectives as well as their tactical objectives.
2. A Trusted Advisor is a problem solver and is not afraid to lead with ideas. Trusted Advisors are malleable in their understandings and are just as happy to learn as to teach.
3. Trusted Advisors have an accountable and accessible nature. They are happy to own their missteps (and those of their team) and work transparently to correct them. They understand that when conditions are at their worst, they need to be at their best. They are easy to contact and always return messages.
4. Trusted Advisors bring the required resources to the table to solve problems. The Trusted Advisor understands that they are not experts at everything and have a strong network of accessible colleagues and technical resources they can call on to help solve their prospect / customers problems.
5. A Trusted Advisor see’s their role as a continuing role with their prospect / customer. They don’t relax once they have delivered an outcome, they simply move on to the next opportunity.
So why is being a Trusted Advisor so important now?
Well historically a salesperson would be coached to take a ‘Trusted Advisor’ position only for high value solution sales. This is still the case for these high value solution sales and is as important as it ever has been. Contrast that with salesperson selling box products. These salespeople were coached to focus on features and benefits and were not necessary burdened with taking this higher order role with their prospects / customers. This was a commercial necessity as the box product sales generally had a very low margin level and the cost of sale was very important. The Trusted Advisor approach to selling is a higher cost approach. In the past the box product salesperson had one job and that was to make sure the prospect / customer clearly understood their products features and benefits including their “Key Value Proposition”. Their role was to continue to communicate these messages so when the decision point was reached by the prospect / customer they would ultimately choose their box over all other boxes in the marketplace.
Fast forward to the modern day and we now find ourselves in a world where many buyers are able to educate themselves online. They can effectively learn about your products features and benefits (including the “Key Value Proposition”) without you. They can research other buyer’s journeys and experiences with your products globally from multiple online networks. The buyer has effectively made the traditional box product salespersons role redundant. So what is your role now?
If you are a box product salesperson and you continue to engage the prospect / customer the way you always have you run the risk of losing credibility. They do not need you to tell them what they already know and if you see that as your job you are missing a huge opportunity. They are craving a deeper relationship. This is your opportunity to become the Trusted Advisor. What is important now is understanding what they are trying to achieve and helping them achieve it with your products and services.
If you are a high value solutions salesperson then you need to continue to act as the Trusted Advisor and exhibit the traits associated with the role. Hopefully this blog has re-affirmed your commitment to this methodology and motivated you to elevate your sales performance to the next level.
Chief Executive Officer
FileBound Australia Pty Ltd
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)
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.