In the second part of our ‘Bridging the gap between marketers and developers‘ series, I’ll outline a handful of techniques that can really help you make your development brief as easy to understand, and as comprehensive, as possible.
When working on Custom Technical Solution (CTS) projects here at dotmailer, there are a number of actions that we take to try and make our development and project management team’s lives that little bit easier. These actions take place all the way from the first conversation we have with the client, right up until the point where we hand over the brief to the project manager and developers to review.
Speak to the key stakeholders
It’s important to make sure you speak to the right people from the start. Even stakeholders who may only be influenced slightly by any potential changes should have their input taken on board, especially if there are conflicts of interest that need to be resolved. If time is not taken to make sure all stakeholders are spoken to, then requirements may be missed, leading to an unsatisfactory solution at the end of the project.
Don’t start technical
Jumping into technical details and possibilities too early can lead to you missing out on the bigger picture. Make sure you understand the business objectives driving the required changes, and where the processes you are modifying/replacing sit within the business as a whole. It sounds odd to say this in a post about producing a technical brief, but there may very well be non-technical options that can improve the process, and don’t need to go in to your development brief at all!
Review the existing processes
Getting a good understanding of any existing processes can be invaluable when it comes to establishing a new and improved solution. Process diagrams, along with the questioning of users and observation of them performing the existing processes, will help to make sure that all of the actions in the existing process are accounted for in your solution and brief.
Establish what data is actually available
There’s no point in constructing a fantastic new solution if it turns out the data that is integral to it working can’t actually be obtained. Obtaining a clear view of all available data and its context within the overall process, as early as possible, is one of the most important parts of the analysis process, as it can make or break a solution. Imagine the frustration of scoping and building a solution that automatically emails recommended local outlets to a customer, only to realize that you aren’t actually able to extract any postal address details from your customer database!
Clearly define the requirements
Once a solution has been agreed by all key stakeholders and any technical experts that you have consulted with, it is obviously very important to make sure that you clearly define the requirements of the solution. Doing this ensures anyone reading the brief, specifically the development team, doesn’t misinterpret what needs to be done, and so end-up producing a solution that is not fit for purpose. Make sure that all requirements have the required level of detail, using techniques such as use-case diagrams or class models to help visualize the requirements if necessary.
Don’t cut yourself off
Once the brief, or project scope, has been passed over to the project manager and/or the development team, ensure that you’re still available and prepared to answer any outstanding or unclear points. Hopefully, if you’ve taken as many of the above steps as possible, you won’t really be required, but in every case, keeping an eye on how the development is going is beneficial for the confidence of all parties.
So that’s your lot. Hopefully there’s something in there that you can take away and action yourself when scoping a project and producing a development brief, but don’t forget you can always talk to us here at dotmailer if you’d rather we just take care of it all for you.
In part three of this series, we’ll move on to the delivery of the project and the importance of having a Project Manager to see everything through.