Estimates and Requirements

This week the tip of the week at http://bit.ly/ciyf0W is about being prepared for the expected and unexpected issues that can impact the project. One of these expected issues is a missed requirement. This happens frequently on IT projects. Software applications can be fairly complex so it is likely one or more requirements may be missed in the original requirements gathering phase. What generally happens with these is that the requirement is added and the project schedule and budget are impacted. A better way to handle this is if you are prepared for it. After the initial requirements are done go back to the estimate and assign a value to each requirement. This serves two purposes. First it gives you a tool to validate and refine the estimates. Second it now gives you a tool for the case of adding a missed requirement. When the requirement is identified estimate what it costs. Now you can go back and see what the real impact to the budget and schedule is. Then the decision could be what requirements can be dropped to account for the new one or maybe the new one can fit into the contingency funds.

An estimating we will go

Restarting the blog this week by looking at project estimating and scheduling.

Check out the PRT web site at http://bit.ly/ciyf0W  to read the tip of the week on the importance of continually reviewing and revising the estimates as the project progresses.

Agile Methods

Is your company ready to use an agile method for their IT projects? Check out the blog this week for discussions on this subject. The tip of the week on our web site discusses what projects make good first projects for an agile approach. Read the tip at http://bit.ly/ciyf0W

Escape Velocity

When an IT project has been delivered sometimes the hardest thing to do is to get out. There usually are post go live defects and issues to deal with. To make sure that you can turn over the delivered application and close out the project you should develop a transition plan prior to go live. This plan should detail how long the warranty period is, who takes over support, what documentation is needed fore turnover etc. Having this plan will help you achieve escape velocity.

1,2,3,4 what are we counting for

This week the tip of the week on the Project Right Track web site, http://projectrighttrack.com/support.html discusses defect rating and prioritization for IT projects. My premise is that we spend too much time worrying about categories then actually figuring out what is most important to fix and fixing it. My tweets and this blog will echo that theme.

Most organizations use a defect rating scale of 1 to 4 or 5 where 1 is most critical and 4 or 5 is a minor or cosmetic issue. In all of my years of managing projects I am not sure I have ever seen a defect rated a 4 or 5 fixed. I'm certain a few have, probably by accident. So why do we rate them. The rating systems are used to help us determiner which are the most important or impactful defects that must be fixed.

Rather than rate theses defects 1 - 4 would it be better to identify the top 5 or 10 and work on those. When those are done, 5 or 10 more could be selected and so on.

By doing this, you are focusing resources on the most critical items and saving a bunch of counting.

"Less is More"

When you validate for a go live weekend make sure there are clear definitions as too how much needs to be done for validation. Today during go live the users processed a lot of work in a short period of time. Unfortunately the validation of each item takes a lot longer than the entry. Thus they could not validate everything in time to make the go / no go checkpoint. We are not sure if we have a problem because we really can't tell what should have worked because of the sheer volume done.  It is critically important that you plan how much work will make a good validation set and stick to it. More is not always good.

Listening is the best communication method

During go live weekends there will be issues found and some defects. When the users who are validating find these be careful not to go into explain mode. Listen to what they say and ask questions about the issue. Is it critical? What is the business impact? Is there a work around? Did this issue exist in production? The more you ask and listen the better the overall communication is which will result in a better outcome.