The Art of managing Freelancers

If you were building a new home, would you jot down your ideas for the house in a short Word document, then send them over to construction workers and expect everything to work out well?



Of course not.




And yet, when it comes to software development, most people do exactly this.



They expect a simple unabridged outline of their thoughts, should be all an accomplished software engineer would need to get the job done.



ARCHITECTS AND BUILDERS



Software engineers need a detailed specification document to work by.



In the real world, when you build a house, you would start with an architect. Your architect's job is to translate your vision into a diagram, with detailed measurements and notes about which materials to use.



A builder then takes the diagram prepared by the architect, orders the required materials, creates a work plan, rounds up the construction workers to do the work and manages them on a day-to-day basis, until the work is completed to your satisfaction.



PRODUCT MANAGERS AND PROJECT MANAGERS



In the software development world, these two roles are played by a Product Manager and a Project Manager.



The Product Manager's role is to translate your vision, into a language software engineers can understand, using very detailed descriptions, screenshots and visuals, not leaving any room for interpretation.



This document is called a Specification Document. Getting it right is the first step in ensuring your project will be a success.



The Project Manager's role is to manage the software engineers until they successfully build a working program that works looks and feels exactly as described in the specification document.



THE SPECIFICATION DOCUMENT



Ideally, it would be best if you have a professional help you with preparing the specification document.



Try to reach out to a Product Manager, who has experience in preparing such documents.



If you don't have access to a Product Manager, your next best option is to reach out to an experienced software engineer and ask for his/her help.



A good specification document should at minimum include these parts:



1. OVERVIEW



Explain what this project is about. Who are the users, what function does it fill and what is the value proposition.



2. GOALS



Detailed list of goals. Be as specific as possible about what you want to accomplish with this project.



Include screenshots and examples of similar websites/services as necessary.



3. TECHNICAL SPECIFICATION



Define the programming language you want the software engineers to use, the target platform and tools they should use



4. PROCESS FLOW



Step-by-step description of all the screens a typical end user will go through.



Include screenshots, or mockups - very important!



5. TECHNICAL ARCHITECTURE & CODING CONVENTION



Explain the architecture of the product, which modules you want to have created and how they should interact with each other.



Provide a link to your preferred coding convention, so that it's easier to later manage the code.



6. BUDGET AND TIMEFRAME



Your estimated budget and target timeframe for the project.

Ask the software engineers to confirm they can meet these, or work with you on reaching a mutually agreed-upon budget and timeframe, before the project starts.



7. COMMUNICATION



Include contact information for your project manager (probably you) and be clear about expecting daily updates from the engineer, outlining the progress of the work.



Make yourself available via Skype, email, or phone.



Be sure you are responsive and insist on getting frequent progress reports, along with links to review the project at every milestone.



HOW TO TELL IF YOU GOT IT RIGHT



Similar to an architectural diagram, a good specification document leaves no room for interpretation.



Two different qualified software development teams, should be able to create the same result, if the specification document is sufficiently detailed.
Full Post