{"id":4521,"date":"2014-04-15T11:31:41","date_gmt":"2014-04-15T11:31:41","guid":{"rendered":"https:\/\/www.gosquared.com\/blog\/?p=4521"},"modified":"2019-11-28T12:11:32","modified_gmt":"2019-11-28T12:11:32","slug":"lean-guide-to-project-specs","status":"publish","type":"post","link":"https:\/\/www.gosquared.com\/blog\/lean-guide-to-project-specs","title":{"rendered":"A lean guide to project specifications"},"content":{"rendered":"

As a lean and growing startup, we hear a lot of advice recommending that there should be no project specifications (specs) at all because they’re a mere formality. However, done correctly, specs (both functional and technical) help us keep our projects on time, on budget and on track. Specs refer to the specifications in product development and are essential for good product management.<\/p>\n

Almost a year ago, I proposed a new way for GoSquared to spec projects during a Lunch & Learn (see the post on L&Ls by Bitly for more info<\/a>). Parts of it stuck, others didn’t. Over time, I’ve stripped the proposed method down to the core. Now, we have a lean and simple system which isn’t overly time-consuming or laborious \u2014in fact it saves time by keeping us on track.<\/p>\n

Initial, Design and Dev Specs<\/h2>\n

Each spec has three parts – functional<\/strong> (initial spec), design<\/strong> and technical<\/strong> (dev spec).<\/p>\n

Initial Spec<\/h3>\n

The initial spec is usually written from the customer’s perspective and by a member of the marketing team. They should be short and concise with a brief introduction followed by points (which could easily be a checklist) of what will make the project a success.<\/p>\n

\"Tracking<\/p>\n

Design Spec<\/h3>\n

If required, it’ll then have design input and notes added – usually in the form of Sketch files<\/a>.<\/p>\n

\"Tracking<\/p>\n

Dev Spec<\/h3>\n

Once the core of the application or feature has been specced out, a member of the development team will review these specs and propose an implementation with rough time estimations. This includes notes on what technologies will be used, any R&D required, and any other significant work that will be required.<\/p>\n

The dev spec is most likely to change during a project as it can have many unknowns. We try not to embark on development until the spec is clarified as much as possible to help avoid overrunning.<\/p>\n

\"Tracking<\/p>\n

Once the dev spec is completed with a reasonable amount of detail, it’ll be passed back to the initial spec author for review. In addition, the CEO James will\u00a0review the feasibility and ensure that the timeframes are reasonable. It’s really important to have senior external input to ensure resources are being put to best use. Projects that will take too long<\/em>\u00a0versus the expected returns are shelved before any significant time can be spent on them.<\/p>\n

The developer who writes the dev spec becomes the project lead and will then manage the time and resources required.<\/p>\n

Evaluating Completed Projects – How can we improve in the future?<\/h2>\n

Despite being a task that returns no direct benefits for customers, reviewing and evaluating how a project went can help teams learn from mistakes and ensure improvements are made on the future. Doing this every time will help the team dramatically improve time estimations in particular. The review also lets anyone on the team see\u00a0what has changed and flag any known issues.<\/span><\/p>\n

\"Tracking<\/p>\n

In most cases, the evaluation only takes a couple of minutes.<\/em> Larger tasks may require a longer evaluation to give a more actionable review.<\/p>\n

How do you manage the individual specs?<\/h2>\n

Using Microsoft Word \u2014or any other non-collaborative software\u2014 for managing the documents is a very bad idea. Specs should be fluid and easy to keep updated by everyone involved. The objective of the spec shouldn’t change, but everything else can and should be updated frequently.<\/p>\n

We use a GitHub repository for managing all of our specs. GitHub enables us to see histories of the specs with ease so we can retrospecively see what’s changed \u2014why did X look like the right solution initially but Y end up being the shipped feature? We also write in Markdown, so there’s easy and consistent styling on all of our documents. GitHub also keeps all the project specifications in one place and provides a central point of reference.<\/p>\n

“Specifications aren’t lean, they’re pointless documents created to please managers.”<\/h2>\n

When specs are done badly, that is often the case. We’ve found that a short spec (limited to a few hundred words in total, including the evaluation) really does help keep everybody in the team on track and has resulted in more projects being finished on time with fewer unforeseen issues delaying everything.<\/p>\n

The result of the specs has been improved communication, smarter allocation of time, and, most importantly, more refined applications and features being released to our customers.<\/p>\n

Further Reading<\/h3>\n