Tackling the Weird and the Wonderful: A Process For Ingesting New Client-Initiated Projects
Created by Kaylea Hascall (University of Chicago) on March 12, 2007
I spent some time today chatting with a colleague about the process we've been following for what might be called "project ingest" -- specifically, when non-IT groups or individuals come to you and say "I have an idea!"....what's next?
I'm in an Academic Technologies department -- I run our projects group. We get some weird and wonderful stuff, filled with unknowns -- so a flexible and creative process that still qualifies as a process is particularly important. Before these get to me, they pass through some kind of filter -- sometimes, the filter is just "the Senior Director says 'Help this person!'", and sometimes, the filter is a group we call START. They support our course management system, and help faculty with short-term projects, particularly ones that can be fulfilled with existing off the shelf products. If we already have something that fulfills most of what they need, they try to fill it that way.
But if not...well, that's where things get interesting :). 3D Modeling? Custom programming? Experiment with a new software package for teaching? Weird new multimedia installation? Innovative technology extravaganza? Hm..........let's talk.
Step 1: Consulting. I usually estimate this as 3 hours per project per quarter. We offer this with no promise of providing anything more, and we write a report on that meeting, as well as any follow-up we agreed to do, from a purely neutral point of view. This is for information only -- it will be useful to us if we do the project, but it may also end up in the hands of another IT group, a funding agency, etc. Some important parts of the consulting report are:
The Project: describe what the person wants to do, as you understand it, with all the components you think are required.
Next Steps: what's to be done next -- broad issues to be addressed, preferably ones that came out in the course of the discussion.
Additional notes & considerations: thoughts, observations, specific issues, small areas of follow-up that you committed to.
I think the best way to do any kind of consulting is to go to the faculty office or the conference room nearest to the staff or students you'll be working with. It can be a little inconvenient, especially if you're going with a team, but I think it says something important when someone in "Central IT" with a capital C makes it a point to get out of their office and stump across campus to the place the clients live. I think it makes the person more comfortable, and thus more able to communicate with you. If there are materials they want to show you or another person who should have been included, then they're sure to be on hand rather than accidentally left behind. I also make it a point at the end to try to open the door to anything else that might be on their mind with respect to central IT. They've got me in the room -- are there any nagging issues I might be able to help with? Things that bother them or other feedback on services?
In this stage, it's important to really listen to the faculty/student/staff member -- and to resist the urge to offer a specific solution to the problem. Ask questions and make observations, but don't quote any prices, or commit to a role in the project. I have a hard time holding back my impulse to Do The Thing Now....but thanks to my Senior Director, I'm learning :)
Step 2: Tech Feasibility Study.
If appropriate, we may offer to do a technical feasibility study. This is a focused bit of research into a particular technical question, and may include anything from a few paragraphs of analysis to a package of demonstration code. We report on this effort and share our results. This study may also result in the production of a white paper.
Step 3: Statement of Work and Project Estimate.
This describes everything we're going to do, and how much it will cost. Even if you're not going to charge for the service, it should quote your rates -- that way they know what you're giving them, and if you need to justify anything later, you have a basis for it.
This is a negotiated contract, based on the consulting you've done, and this is where the committment and the specifics start to play a role. Once you've done 1&2, this part is fairly straightforward.
Step 4: Service Level Agreement.
This part is new territory for us. In the past, we've described our scenario as "best effort" -- we have this much staff, and they'll work very hard for you if something goes wrong, but if you need someone to carry a pager 24/7, we need to bring the data center into the mix. Increasingly, however, we're feeling the need to quantify that "best effort" a little more tightly. I'm part of a central IT working group which is working on defining our approach to SLAs.
So, that's what I have so far. I'll probably modify this in the future, and perhaps add some links to samples. Comments? What's your project ingest process? Hm, that sounds like a name for a punk band -- put your hands together, people, it's the Project Ingest Process! (Yawwwwwwr!)
I'm in an Academic Technologies department -- I run our projects group. We get some weird and wonderful stuff, filled with unknowns -- so a flexible and creative process that still qualifies as a process is particularly important. Before these get to me, they pass through some kind of filter -- sometimes, the filter is just "the Senior Director says 'Help this person!'", and sometimes, the filter is a group we call START. They support our course management system, and help faculty with short-term projects, particularly ones that can be fulfilled with existing off the shelf products. If we already have something that fulfills most of what they need, they try to fill it that way.
But if not...well, that's where things get interesting :). 3D Modeling? Custom programming? Experiment with a new software package for teaching? Weird new multimedia installation? Innovative technology extravaganza? Hm..........let's talk.
Step 1: Consulting. I usually estimate this as 3 hours per project per quarter. We offer this with no promise of providing anything more, and we write a report on that meeting, as well as any follow-up we agreed to do, from a purely neutral point of view. This is for information only -- it will be useful to us if we do the project, but it may also end up in the hands of another IT group, a funding agency, etc. Some important parts of the consulting report are:
The Project: describe what the person wants to do, as you understand it, with all the components you think are required.
Next Steps: what's to be done next -- broad issues to be addressed, preferably ones that came out in the course of the discussion.
Additional notes & considerations: thoughts, observations, specific issues, small areas of follow-up that you committed to.
I think the best way to do any kind of consulting is to go to the faculty office or the conference room nearest to the staff or students you'll be working with. It can be a little inconvenient, especially if you're going with a team, but I think it says something important when someone in "Central IT" with a capital C makes it a point to get out of their office and stump across campus to the place the clients live. I think it makes the person more comfortable, and thus more able to communicate with you. If there are materials they want to show you or another person who should have been included, then they're sure to be on hand rather than accidentally left behind. I also make it a point at the end to try to open the door to anything else that might be on their mind with respect to central IT. They've got me in the room -- are there any nagging issues I might be able to help with? Things that bother them or other feedback on services?
In this stage, it's important to really listen to the faculty/student/staff member -- and to resist the urge to offer a specific solution to the problem. Ask questions and make observations, but don't quote any prices, or commit to a role in the project. I have a hard time holding back my impulse to Do The Thing Now....but thanks to my Senior Director, I'm learning :)
Step 2: Tech Feasibility Study.
If appropriate, we may offer to do a technical feasibility study. This is a focused bit of research into a particular technical question, and may include anything from a few paragraphs of analysis to a package of demonstration code. We report on this effort and share our results. This study may also result in the production of a white paper.
Step 3: Statement of Work and Project Estimate.
This describes everything we're going to do, and how much it will cost. Even if you're not going to charge for the service, it should quote your rates -- that way they know what you're giving them, and if you need to justify anything later, you have a basis for it.
This is a negotiated contract, based on the consulting you've done, and this is where the committment and the specifics start to play a role. Once you've done 1&2, this part is fairly straightforward.
Step 4: Service Level Agreement.
This part is new territory for us. In the past, we've described our scenario as "best effort" -- we have this much staff, and they'll work very hard for you if something goes wrong, but if you need someone to carry a pager 24/7, we need to bring the data center into the mix. Increasingly, however, we're feeling the need to quantify that "best effort" a little more tightly. I'm part of a central IT working group which is working on defining our approach to SLAs.
So, that's what I have so far. I'll probably modify this in the future, and perhaps add some links to samples. Comments? What's your project ingest process? Hm, that sounds like a name for a punk band -- put your hands together, people, it's the Project Ingest Process! (Yawwwwwwr!)
Bookmark/Search this page with:
Otherwise, many of our faculty-initiated projects follow the pattern you describe. One recurrent constraint is that grant budgets don't always allow a great deal of technical scoping - sometimes, the scoping work IS the project! For me, consultation with faculty/partners is vital, the tension is always that resource is never infinite, so the question is how to bound the initial consultation process and manage expectations. We've previously used the JISC project management guidelines for longer projects, but for small-scale, rapid-prototyping work they are a bit heavy-handed and not really appropriate.