Finalizing Project Specifications

As the team lead for the past year, I’ve been playing the role of politician, requirements gatherer, specifications writer, and project manager for VISI’s development team. Requirements and specifications are something completely new to VISI’s development projects since I started taking ownership of them. Upper management has been asking for more quality and this is one of the steps we’ve taken to reach that goal.

I won’t go into detail about how to gather requirements or build a specifications document at this time, but I’d like to inform you how I’m “finalizing” our internal project specifications so we can starting building out the project. Two of the projects I’ve been preparing specifications for have come to a close just yesterday and today. One of them is a small project that is projected to take 8 days to build out and the other is a large project expected to take many months. After many revisions of the specifications document for each project and repeatedly asking for, and not receiving, an approval from the “customer”, who is an internal employee, the revisions just continued creeping in slowly for a couple weeks time.  This is not productive time and is only delaying the project, especially when you have a developer on your team looking for something productive and meaningful to work on.  The project “customer” may have trouble committing to a specification, knowing that changes during the build and after launch are harder to come by. They may also be indecisive for fear of making a commitment and overlooking an important requirement or feature.

Because this is an internal project for the company, I am able to “help” facilitate and keep things moving.  It’s very simple: the company needed this project completed yesterday, so we need to draw the line and get started.  For you sales people out there, “asking for the sale”, or “close”, did not work with these projects.  Therefore, I’ve realized it’s up to me to draw the line and tell them when the specifications are finished.  How do you know when this time has arrived with a project spec? When the change requests and revisions have slowed and decreased in severity to the point where you’d be able to makes the modifications very easily on the fly during the project build.  I’m not saying it’s good to make a bunch of changes to the spec during the build, but they will come inevitably and will never cease, even after the project is completed.   The other important factor is that your team is ready to get started.  If you’re developer for the project is tied up for another month with something else, then there is little need to bring closure to the specification discussion at this time since you know little changes and modifications will forever continue with larger projects.

When it comes to the internal project that is starting to drag on forever, just remind yourself and the internal “customer” that the company needs the project completed and a line must be drawn.

Leave a comment

Your email address will not be published. Required fields are marked *