Posted by: Daniel Boterhoven on Sat Aug 07
Delegation not only frees up your time to focus on growing your business, but also helps maintain your sanity when the list of things you need to do each day grows.
With delegation comes the need to effectively communicate, so that the person you’re delegating to can take your instructions and complete the task at hand. They also need to do this properly and with minimal help from yourself.
This is why creating the perfect task specification, or task spec, can make or break a project before it’s even started. As a tech lead, I’ve learnt over the years how best to do this, so that any project has a better chance of running smoothly and with minimal hiccups.
One of the most important steps in the process of creating a spec, is to first fully understand what you will be asking your developer to do. For the developer to understand your vision for a project or piece of work, you need to clarify it in your own mind first.
There are a few criteria that you need come to terms with:
Spend time considering these criteria and be sure to write them down for your reference at a later date. Your answers may change, but it’s good to keep track of these details in order to keep yourself and your developer focused on the task at hand.
Having collected your thoughts, it’s now time to write a one-page description of the project. The primary purpose of this document is to give your candidate, or candidates, a high-level overview of what’s needed. We will get into the nitty-gritty later, but for now we just want to get their feet wet and prepare them for more detailed discussions later.
Your document should start with a description of where your project or business has come from and the reason it started. You may not think it overly necessary to include this sort of information, but trust me, it will help the developer to know where the project began and why.
Without this sort of information, the developer will have less context and will be less in sync with your needs.
Next, explain your immediate need for a developer. At this point, you can specify what skills are needed, what kind of work they will be doing, also how and with whom they will be working. This is also the time to articulate what their role in the project will be.
Along with their role, you will explain the factors that will constitute success on their part, once the work is completed. These are the goals you detailed in your initial project brainstorming. Being clear with these will help ensure that the developer fully understands their responsibilities and is prepared to take them on.
In order for your developer to understand their ongoing involvement in the project, it is good to articulate where the project will go after the immediate work has been completed. Developers will often be on the lookout for projects that provide the opportunity for continued work, so including that here could make the spec more attractive.
Being clear about the timeline and budget is a necessity to keep expectations realistic. Explaining these in your spec document is a must.
Worth noting is that it’s critical to stay on top of these as the work progresses. Estimating timelines and managing budgets in software development is notoriously difficult – it’s highly likely they will change.
Make sure you mention in your one-pager what your expectations are with regards to availability. If you plan on holding daily progress meetings (a good idea), ensure you state this so that your developer is aware of your requirements.
Clarifying expectations early on regarding availability and punctuality helps ensure communication lines stay open during the course of your project, and you’re less at risk of your developer going AWOL.
Having written your one-page project description, it’s time to move onto wireframing. In case you’ve never heard of a wireframe, here’s a great description from Wikipedia: “A website wireframe, also known as a page schematic or screen blueprint, is a visual guide that represents the skeletal framework of a website.”
Not only are wireframes a great companion to you project description, they also help you flesh out the user interface before any coder gets underway. This helps to keep costs lower, as design issues are far easier and cheaper to solve at wireframing stage than they are at implementation stage.
Wireframes are perfect for communicating the visual layout of a screen. They’re great at explaining to your developer what is needed from a visual perspective. Accompanying your wireframes should be text explaining the behaviour and functionality of the elements in your wireframes.
These descriptions should leave nothing to the imagination, and they should answer questions before your developer has the need to ask them. After all, we are trying to ensure your developer has everything they need to work on their own. 
Figure 1: Wireframe example
With your one-page description, wireframes and accompanying behavioural text complete, it’s time to share the spec with your developer. I find the handing over of the spec to be equally as important as creating it in the first place.
Send the developer the spec first and give them time to review it. There’s no point putting the spec in front of the developer in a meeting and then immediately asking them if they have any questions. As with most things, humans need time to digest this sort of information and to independently develop an understanding of it.
Having given the developer time to properly read through the spec, arrange a face-to-face (or video) meeting to go over it in detail. By now, the developer will most likely have a number of questions for you. After a bit of back and forth, they will gradually grow to understand the details of their potential role in the project.
At this stage, it is a good idea to ask your developer for feedback regarding the spec. This has multiple benefits; they may uncover issues that you have missed, and if they ask the right questions, it will increase your confidence that they have understood the spec correctly.
The last step in sharing the spec with your developer is to confirm that their deadlines and budget are realistic and achievable. If they agree and you’re both happy to proceed, work can commence.
An unclear or inadequately defined spec will increase the chances of your requirements being misinterpreted. This will ultimately increase expenses, as extra work will be needed to correct avoidable mistakes.
Communicating your project requirements clearly and effectively will increase the chances of your developer reaching their goals. This will, in turn, add to the success of your project as a whole. So, next time you need to delegate work to a developer, keep these tips in mind to help ensure the work gets completed on time, within budget and in line with your expectations.
Have a web or mobile application project that you’re looking to get off the ground? We can help. Get in touch via our contact us page to see how we can help.
…
Subscribe for updates