Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
Answering my recently asked question whether to "deliver results when finished significantly prior to the agreed deadline", Smandoli suggested to fill the slack with "Look for places to exceed expectations, exceed the spec."
I understand that deciding whether to do work which goes beyond defined project scope depends on a number of factors. Which ones do you consider to be particularly important to make a qualified decision?
Be careful about exceeding expectations based on 'having time to do it'. I've been on the client side of this behaviour and my reaction was not what the team expected. If I had been given the choice, I would have asked for completely different use of the time. No only did the team not exceed my expectations by deciding what they could do, the didn't meet my expectations because of their actions.
My suggestion is to give the client the options. Remember, they might just be happier to have the early delivery, rather than have what you determine is 'extra' value.
Tricky subject because so many projects pivot on the client expectations - which often don't match up to the written specification.
You could deliver the core product early and ask the client which areas they would like improving.
You could guess and produce something that is extended in areas you think are important.
You could just deliver early!
You could show the client what you have done and then the client may well point out that they had a different expectations of sections 2,3,6 and 7 - and could you re-work them?
I remember reading a case study on the iPhone UI project, where they decided to exceed expectations in areas that would make the phone seem special like the touch screen and zooming in/out - but almost ignore humdrum elements like cut-and-paste - and that was what lead to the huge approval ratings.
So if you are going to exceed expectations the iPhone lead is worth considering.
I'd say in any scenario there should be some gain either for you or for the customer and possibly for both sides.
A few ideas to consider which come to my mind:
Depending on a type of project, you may add something which pleases the client but also makes you product better for future implementations. Not only should you consider this specific implementation but also potential future ones.
Another factor to consider is paying some technical debt back. Vast majority of projects I know incurred at least some technical debt and such situation is a good occasion to do something about that. It usually pays of in terms of maintenance cost.
This brings me to another thing - there are some features which reduce maintenance burden and cost, automatic updates being the most obvious example here. They usually are win-win which makes them good candidates to consider in such scenario.
Just be aware that everything you deliver exceeding specification, and so an existing contract, cannot be sold, and you will probably never get any money for it.
I vote no on this under most if not all circumstances. This runs too close to the line of scope creep. Projects finish earlier or later than targets all the time, secondary to nothing more than random events. Most times, we finish later due to our uncanny ability of estimating too optimistically--planning fallacy. If you finish early, capture the favorable variance and move on as planned because you will likely need the slack later when you begin to overrun a succeeding package.
Well I think its a perfect case for Agile style project management. If you are operating in an Agile fashion then you have a few of things.
1- When the project, as defined is done, you can ship it. 2- You are communicating with the customer regularily. This allows them to adjust what they want. You won't be done and wondering if you should add more, the customer will tell you. 3- With a well defined and groomed backlog you can easily reach for the next items on the backlog.
To be my own Devil's Advocate, you have to be very careful in what you ship, if it will be used by an outside consumer. If you add a dozen new features to your database and no one tells customer support about it, they'll be trying to support a product they don't know. This just stresses the need for total team communication. Even in an Agile development process you can have groups like customer support ready to go the moment you ship.
