Combatting Tool Creep
Posted August 1st, 2007 by rybolovNo, I’m not talking about the guy at your local automotive garage co-op that signs out wrenches. What I mean is something similar to what a project manager would recognize as scope creep.
Imagine the scenario: You’re a managed service provider and have a variety of tools to do the following things:
- Monitor servers
- Monitor network devices
- Archive/review logs
- Automatically generate trouble tickets
- Manage NIDS
- Manage HIDS
And then along comes a client request out of the blue that surprises you. Say, for instance, they want to generate an automatic feed for an asset management system. It’s a great idea, but you don’t have a tool that can do it, then you end up buying something new.
Normally this is a problem for the typical IT shop. For a Managed Service Provider, it’s what will kill you. Either you support a tool for all clients, or it becomes a one-off for that particular client, and that’s bad because then you end up with every client having their own peculiarities.
So the big question is, how do you handle tool creep? Well, about the same way you handle engineers messing around with :
- Train your people on what you have build already and manage attrition.
- The Technical Review Board if you have one can/should do tool evaluations and selections.
- Look at plugins for the existing toolset that you have–can you get the same effect with an additional license/module or teaching a new group of people how to use what you already have?
- Make the new tool ODC–Other Direct Charge. IE, carry through the cost to the customer, including design and implementation.
Similar Posts:
Posted in Technical, The Guerilla CISO | 2 Comments »
August 1st, 2007 at 10:20 pm
A previous company I worked for had a slightly similar problem. As an ASP, we regularly had clients ask for features in our web app that were not built, and sales, being sales, ignorantly would say yes and sign the dotted line. Creep is a killer, not just for the bottomline, but for morale as well. Creep like that and what you describe is ok, if you’re providing a true service. For many MSSP shops, I would say they prefer (or should prefer) to provide more of a product; i.e. something that is roughly the same from client to client.
Consulting and true service providing is where you can charge for the creeps.
(Note: I use service and product in the above as the two things people/companies sell. Services are customizable like hiring a developer to make your website; products are the same from consumer to consumer, like Windows OS software. As such, that leaves terms like MSSP in a sort of confused void if you’re not careful. 🙂 )
August 2nd, 2007 at 9:50 am
The biggest problem for us is that our services are a fixed-cost bucket. If you add more things into scope, the bucket can’t hold anything else.
That’s why you need a detailed description of your standard service offerings and a method to do out-of-scope work for cost or cost plus a bonus. =)