Creating strategy is fun, but implementation can sometimes seem a little more mundane, and it’s also a bit more tricky. This blog and the accompanying EXERCISES will make it a lot less daunting and you might feel you want to involve a good professional consultant somewhere from now on. An external resource will often spot things you miss just through having a different viewpoint, and also be able to provide insights from his or her experience and understanding of the technology and what it can do.
This article will help you start to establish a set of functional requirements so you can take your strategy and turn it into reality. Future posts will examine possible technical solutions.
Introducing the functionality matrix
This is a project scoping and management tools used in systems implementation that helps to visualise and manage a set of system requirements. First, identify broad functional areas (good examples might be ‘Customers’, ‘Projects’ and ‘Email’), then split each of those areas into defined individual functional requirements.
Functional requirements are definitions of what you want a system or process to do. Its title should be two or three words that say exactly what it will do (a verb and object(s) like ‘Manage Customers’, or ‘Send Escalation to Manager’), together with some description text.
Here are some examples of good functional requirements:
| Title | Description |
| Manage Customers | List customer records and provide drill-down to edit detailed fields and contacts. Customer list should be sortable and searchable on a number of parameters, and should allow inline editing of main fields, eg status. |
| Send Escalation to Manager | When a project is approaching deadline (the exact time point depends on the type of project), send a notification by email to the project manager. For high priority projects, notify project manager and also chief operating officer by SMS. |
Both of these provide a good overview of what is expected of the system, without going into an in-depth description. There are obviously details to flesh out, but there is very little ambiguity and a software provider should easily be able to say whether they support it, and if not how much work it’s likely to be to implement.
Here are some less good ones:
| Title | Description |
| Update Customer Status | Allowed values are prospect, active, past customer. Also flag up customers who require attention. |
| Notify Managers | Managers should be notified when there are projects that need their urgent attention. |
Why not so good? The first manages to be overly detailed and completely ambiguous at the same time. Unless they drive specific workflow, we don’t need to know field values at this time, and the ‘Update Customer Status’ requirement should be part of the ‘Manage Customers’ one above. The second sentence is completely ambiguous as it provides no information as to what ‘flag up’ means, or how we can tell if a customer requires attention.
The second requirement likewise is very ambiguous. Who are the managers, how should they be notified, and what is classed as a project in need of urgent attention? A better description might read “The Operations Director should be notified nightly by email of projects with more than one overdue task”.
The trick is to think about what sort of questions are prompted by your functional descriptions. If the questions are about detail such as screen layout, what technology might be used, what values a field should have and so on, you’ve probably got it about right. On the other hand, if the questions are about defining the words used in your description, what you’ve written is probably too ambiguous. If there are no questions, it’s probably too detailed.
Next, use the titles to create the matrix. The rows represent your broad functional areas, the cells the individual requirements.
|
| 1 | 2 | 3 | 4 |
| Row A Customers | Manage Clients and Prospects | Manage Client Contacts | Segment Clients and Prospects | Log Sales |
| Row B Projects | Manage Projects | Manage Project Tasks | Allocate Tasks | Log Time |
| Row C Communications | Log Inbound Email to Client | Send Outbound Email | Send SMS |
|
This is a simple version; yours will almost certainly be much bigger. Each of the cells should have a description behind it, which is normally kept in another table or spreadsheet. The descriptions will look something like this:
| Cell | Title | Description | Business Benefit | Complexity |
| A1 | Manage Clients and Contacts | List customer records and provide drill-down to edit detailed fields and contacts. Customer list should be sortable and searchable on a number of parameters, and should allow inline editing of main fields, eg status. | 1 | 1 |
| A2 | Manage Client Contacts | Capture all key contact information, including role, and associate to client/prospect record. Also allow searching of contacts by name. | 1 | 2 |
And so on. In our functionality matrix template (see exercises), there is a sheet for each ‘row’ with the cell numbers across the top.
You’ll notice extra columns for business benefit and complexity. Here, rank business benefit from 1 to 3 or 5, with 1 being the most important. For complexity (and you may need the help of your technology specialist here), rank in the same way but with the lowest number being the simplest. This is where the matrix starts to become really powerful, because by adding those two numbers together you can get a rough approximation as to what order to do things in, especially when combined with the information flow prioritisation you did in earlier chapters. Colour in your matrix cells according to your prioritisation, and you suddenly have a very visual tool for mapping your project. You can add in another colour for items completed, so that you can gradually see the progress of your project.
In fact, the functionality matrix can be used as the basis for your entire project management. It should be possible to put time and cost estimates against cells, and each task required to complete your project can be assigned to one or more cells.
So, time to crack on with our functionality matrix exercise!
The next post will start to examine how to translate your requirements into choosing a system, beginning with the pros and cons of bespoke vs off-the-shelf systems.