- With the mountain of work ahead, many PM's have to much on their mind to even think about what the end delivery is like.
- By the end of a project, with burnout, turnover, etc. - many teams are not in condition to deliver the product.
- The scope changes, development changes and user changes make the final platform an unknown until near the end of the project.
- Conversion from an existing platform
- Production environment setup
- Training
- Communication/Marketing (telling people the thingy is available)
- Cut Over - freezing the old and turning on the new
- Pulling the switch
- Monitoring for x hours/days to make sure of performance and stability
- Cleanup - delivery of final specs, training, minor (hopefully) fixes
- PAYMENT! (hopefully)
- Party - no matter how things end up - a cold beer helps decompress
To understand the end game, you need to put yourself in the place of being live with the system, say on day-x. You need to work your way back (not aways the best thing to do, because that means project time line compression), hour-by-hour and day-by-day and determine what tasks need to be done to get you to the final day-x. What external groups are involved? When do you need to communicate to them by? Are there any additional charges based on their work? Are there any holidays, financial periods, etc. that need to be taken into consideration?
Once this is done, since some back dating of tasks took place, recheck your project and see if the tasks leading up to the delivery phase are impacted, if so they you'll need to move-out the delivery phase to a later date (mmmm slippage - not a good thing).
Right around the time you're thinking about delivery, you should also be thinking about the end results DID THE PROJECT DELIVERY ON WHAT WAS ENVISIONED? Were the success factors met? Time to objectively see where you are, time keeps moving.
No comments:
Post a Comment