A New Service Blog From an Old Friend

By Larry Laux
President and Founder

Recently Mark Vigoroso jumped into the world of blogging. For those of you who don't know Mark, he was the Chief Research Officer & SVP of Service Chain Research at the Aberdeen Group for the past five years. During this time we worked with him on several Aberdeen Group and Metrix joint projects. Mark has recently taken on a new role as the Chief Services Strategist at nPhase, and we wish him the best of luck.

His blog, found here, is also planned to cover topics relating to Service Management topics. Welcome, Mark, the water’s fine.

Certainly his self-confidence is not lacking. Taking the url ‘ServiceChainGuru.com’ shows that. Even so, he is a good guy and he does have good background and experience in this field. I’m sure he will have useful and insightful things to say, and I suggest you read his work.

The Discipline of Project Justification - Part 5

By Tom DeVroy
VP of Sales
Fifth in a multi-part series

My apologies for being absent so long. It’s been a busy time around here at Metrix. I’ve been amiss in my posts. Nonetheless, back to the task at hand. My previous posts had to do with proving to management that your request for money to acquire a new solution would be backed by conclusive evidence of a well-run project.

Up to this point in the series, you’ve created the business case, done your research and explored alternatives. Perhaps you’ve started to build a financial justification and you have adequately explored your options and evaluated your risks. A key variable in deciding to move the project along is the evaluation of the impact on the business from a personnel or resource perspective.

Besides how much ($$$), managers want to know who and how long. I have a prospect I’m dealing with right now in a very similar situation. They have indicated they have the budget, they have established they have the need, but are fearful about having the available resources to dedicate to the project in order to guarantee success. Consequently it appears that they have deferred their decision to move forward.

Most software vendors have a methodology of some kind they follow to assist customers in the implementation of their software. I would argue that any vendor that cannot provide such documentation is likely one not worth doing business with.

Ask the vendor for a straw man proposal for implementation. Here you want to understand:

1. What does the task list look like?
2. Who is responsible for what tasks?
3. What impact does this have on existing processes?
4. Who is involved from the customer’s staff to work on what tasks?
5. Are there both IT staff and business representation on the project team?
6. What is the estimated duration?
7. Do tasks run concurrently?
8. Any chance to compress the timeline?

The idea is to get a handle on implementation planning at a high level. This provides some level of comfort that you have thought through the operational impact and affect on existing personnel when you start the project.

Next time around I’ll discuss a similar topic in getting your project plan. Defining what the change management plan is to the management team. In other words, how do we get everyone to buy in to the changes you are about to make.

View Part 1 Here
View Part 2 Here
View Part 3 Here
View Part 4 Here