We are beginning a new budget/planning cycle and I wanted to provide some definitions to our planners for consistency. In the past we have two categories of IT work which are Projects (which includes a bucket of time for small enhancements) and KTLO (Keep the lights on)activities. We classify our admin time (department meetings, training, etc.) into KTLO. I'm having a bit more trouble describing the definition and criteria of what type of work goes into our Project category. Okay, Okay, I know the PMI definition i.e. has a beginning and end, etc. What criteria do some of you use for example - a project has to have 2 weeks worth of work for at least two people. I'll just open this up for your thoughts. Anything would be greatly appreciated. Saving Changes...
I'd be careful about putting arbitrary limits on the definition of a project by size. If you were to do so, let's say using your 2 weeks for 2 people criteria, how would you manage them? On what would their promises be based, and how would you avoid the possibility of your carefully planned bigger projects suffering from "being pecked to death by ducks" as resources are siphoned off for these little jobs.
If the small projects are truly small, they should be able to be quickly and easily planned, and if they aren't involving some drum/bottleneck resource, just as easily slipped into a synchronized pipeline of work.
Saving Changes...
Anonymous
You have raised an interesting question. We are working this through also.
Some considerations are things like:
maintenance/minor development (eg a person needs a report to have new data)
enhancements eg a whole new report is needed
major developments a whole new system for generating reports is needed
These look at the nature of the work to be done. Another way of looking at it is the source of the work and the required approval This will probably end up back at estimated dollar value
I am keen to keep an eye on this discussion and see where it leads. Saving Changes...
Okay, for all of you watching this discussion - now is the time to contribute :-). I have a rough draft of what I am going to send out to my folks. Give me some input and thoughts - they would be greatly appreciated. Saving Changes...
Our version of KTLO, LODO (lights on, doors open) does not include administrivia--that gets charged to standard work.
What distinguishes a project is that it has an end date, whereas LODO work does not.
Other features of a project are:
There is a scope of work; The work is planned and the approach is part of a strategy; There is a work breakdown structure; There are deliverables; There is a budget; There is some kind of team structure involving roles; one individual can fulfill multiple roles. Saving Changes...
My 2 cents worth - drop the X time limit - by putting that in you are making a rod for your own back - what happens if it is X+1 day, or X-1 day? How can you justify the differences in strategies?
What you call KTLO I would define as Systems Administration, Applications Administration, Support, Office Administration, Planning (your time!) & Training. Just because you define a 40 hour task as a "Project" doesnt mean you have to go for the full SDLC (I wont get shot for saying that will I?).
Whatever you do, remember the KISS principle - if someone is going to spend a week on a "project", then the amount of effort you put into managing (and planning) that project, should be (roughly) proportional to one that will take your whole team several months. ie If you need someone to change some reports, then;
1 - your instructions on what needs to be changed basically becomes your requirements document - all you need do is work out how long and let them at it.
2 - Tracking can (sometimes) be ignored, and
3 - Sign-off is there as normal as part of any "application fix".
Just becuase it is labelled a "project", dont assume you have to create an A4 ream of paperwork.... Saving Changes...
