» Wrapping up the Project: Completing Deliverables >> The Retrospector

Wrapping up the Project: Completing Deliverables

Posted July 17th, 2006
Categories: Technical, Planning, Project Management, Time Management

One of the crucial points in a project is near the end where you have to decide to simply wrap things up enough to deliver. The ability to enhance the product forevermore can creep into your scope so easily if you let it. (Scope Creep) Sometimes it gets to the point where you’ll be on an endless timeline of development where you can’t just finish it and get the product shipped.

What I’d like to talk about in this article are some of the things to watch for to make sure you can get your product delivered to your customer. Such things include avoiding scope creep, properly comparing requirements with personal opinions, and follow-through on making sure your product gets to a deliverable state.

Scope Creep

creep This is a subject that probably has enough issues that it could be an entire series of posts. What I think you should take away from this for today’s article is simply that allowing the scope to broaden or change too much will prevent you from every being able to clamp down on the “moving target” deliverable. You will spend so much more time trying to factor in new features or implementation approaches for a dynamic scope than ever wrapping up the ones you currently have on the table that you will never get the original requirements in a deliverable state.

During the lifetime of the project from concept to delivery, you absolutely must delay new features such that they be brought back into the picture after the first delivery unless the stakeholders are willing to deal with a huge time delay. Check out my post on knowing when to experiment and when to deliver for more related points on delivery focus.

Want or Requirement?

Another factor to focus on until you can ship the product is making sure that everything you build is something that is a defined requirement of the users involved. I’ve seen a number of companies make the mistake of just having the IT group build what they think the users should have because of their own perspectives as opposed to following what the industry standards are and/or user analysis that shows what the users really respond to. However, I’ve also seen the tables turned where nobody listened to the IT group when it should have been more of a collaboration.
When you’re given a not-so-complete description, how do you fill in the blanks? Do you just assume you know what is needed or do you just take a leap of faith that whatever you come up with that you would want is what should go into the product? Take it from me if you don’t like to rework everything you do multiple times…get the opinion of the users unless it’s simply not feasible to do things any other way within your allotted time. Something you think it should have or want it to have is not the same as giving only what is needed even if what’s needed isn’t cool or even standard. Work up to the requested deliverable, not what you think should happen at the expense of slipping deadlines. If you absolutely have to add or remove things in order to properly implement what’s already requested, make sure you have buy-in from all the stakeholders or you could be in for some rework.

Deliver it!

deliver Get on with it already! OK, basically in order to get this product to the customer you have to draw the line in the sand and finish something. if you work with a continuously integrated environment this shouldn’t be too bad each time you finish a feature of the application since it will already be in a somewhat deliverable state. If you’ve got 10 features you’re trying to work in at the last minute because you have some extra time from finishing early you’re in for a big surprise. There’s no way anything beyond a simple cosmetic change agreed to by most of the team will make a solid introduction to the customers without some major QA involved.

Don’t get into the “endless QA cycle” by tossing more development pieces onto the end of your software lifecycle when you should be in a final QA state while seeking signoff from the customers. For every little tiny change you make to your software, you’re going to be adding dozens of man-hours to the timeline to make sure it’s backwards compatible with everything you’ve already developed.

Take it from me that sometimes it’s better to just get 90% of the application working first to get it out the door covering all of the major use cases in your application so that the users can at least use something until you get your patch out that will handle the next 5% of the scenarios a couple of weeks/months later. Before long you’ll have 99% of the scenarios covered and you will still be known for being able to deliver as expected.

Don’t fall into the trap of not being able to deliver just because you let too much into your realm of control without really being needed. How do you avoid the pitfalls of a non-delivery schedule? What things can you control to make sure you get your software to the customers when expected even when they change their minds more than you change your iPod songlist? Share your thoughts, I’d like to see how everyone else handles such issues.

Tags: project+management, project+delivery, scope+creep, requirements