What is Throw Away Work Really?

Every information management project has a certain amount of waste; it is inevitable. Throw away work that is staging as a means to an end, in other words, a goal’s goal’s goal. The larger picture trumps what seems to be stupid at the doing level. Doers occasionally need to visualize their work as scaffolding. It is there to support the process temporarily, making it possible to work on the actual project. As the image suggests, no work is throw away, there’s always the experience and learning that is invaluable the next time.

The whole goal might be to move off of one platform and on to another. If you stay long enough at one company, you will experience this at least a few times… This type of goal depending on the size of your user dependency and content could be a Mt. Everest climb. The staging would be all of the interim work.

Interim Nuts and Bolts Stuff

Here’s a typical list of necessary Interim throw away activities:

• Upgrade the OS and database to meet the new software’s support requirements.
• Export content and metadata to a temporary storage area
• Map and process data to conform to the new build
• Train Users on new platform

Here’s what might not be necessary:

• Rewrite existing customizations to work on the new platform. The new software’s functionality will most likely leap frog these. A thorough analysis is warranted here.
• Migrate to a half-way point to meet a C’s deadline

1%er Deadline

If you are lucky enough to be a part of incentives to meet your company’s goals, then this may not interest you, but for the rest of us it should. For large projects, the incentives increase as you go from the doers, to the managers, directors, and C’s. These are usually tied to deadlines whether they are realistic or not. As I have said in other posts, quality and overall costs suffer when deadlines are imposed without total buy-in from parties involved. Capital is used for contractors who estimate work based on previous jobs and have a huge list of assumptions. Basically, it’s a trap of change orders within the big project’s budget.

What was really thrown away?

As the scaffolding is taken down, revealing the latest and greatest solution, we have to feel a sense of pride in completing it. No work is completely useless, it has worth; at least I like to tell myself that. Maybe you learned a new framework, or a coding language, or how to do a traceability matrix.

In retrospect, a project is never really finished anyways. There’re always follow up phases; “Nice to haves” put off until after go live. So try to take solace in being a cog in the process and look to the future of doing it with more coordination and influence the next time.

Budget Black Hole

Why is it that almost every IT project has a budget based on guestimates, bound by fuzzy scope, and goals that are usually too constricted? Every time a project methodology is executed, the budget is in the books, not to be revisited. It is just a given, not flexible and not based on specific enough goals. Management will assure us that changes can be made, but how often does that happen, and which projects take priority by the end of the quarter (or bonus time)?

Goals

You can’t just say, for example, that our goal is to do “x” to content by the end of the first quarter. The first you hear about a project, it’s your responsibility to ask, “What are the specific goals?” and “Were these goals fully funded?” Asking questions like these will give your project manager pause, especially if you ask, “What are the success criteria?”

Success Criteria

Large companies have ways to pay for projects from other capital budgets to assure some form of success. The issue is does this success include all of the long-term aspects associated with a strong solution. When it comes down to the wire, we know that testing and quality will suffer if corners are cut from lack of money.

Here are some tips on creating success criteria.

• Combine at least two aspects of success together, for example, migrate all content with 100% accuracy and on time. Notice I didn’t include how much it will cost.
•  Include a stabilization period after go-live because there are always unanticipated issues after a large deployment. This will give the extra confidence that managers and Users need that issues will be resolved in a timely manner.
• If a project is large, then don’t just break out the normal parts, breaking it out to smaller projects which can fulfill smaller goals, with the common understanding that whole will be larger than the parts.