For many of you, being a very technical focused professional has helped designing and deploying some very complex projects. But if like me, you like to get your hands greasy with the guts of the beast, you probably try to dodge the political, sales and budgetary discussions in the projects you work on.
However, when you are specialized in a line of products like the Microsoft System Center family, just the technical skills will leave you in a complicated situation, particularly when you’re dealing with System Center Service Manager.
Based on the ITIL and MOF (Microsoft Operations Framework) concepts, Service Manager’s goal is to help you implement many IT related processes, including helpdesk management, private cloud, user provisioning/termination, etc.
The out-of-the-box experience look will be familiar to the ITIL professional, with Incidents, Problems, Changes, Releases and Activities as work items available right away.
But as in anything in IT and mostly in any other business, there shall be customizations. And here is where your people, project and process management skills will be needed. Just paying attention to the technical side will probably leave you back and forth with the changes of mind of the stake holders.
So, to summarize, here’s a small list of gotchas I have seen in the field with that kind of implementation. If you wish, the basic laws for Service Manager implementations:
– Plan, plan, plan – due to the nature of the hierarchical structure in Service Manager, it is easy to add, but hard to change or remove. Your base classes, properties and types need to be as well defined as possible in the beginning, to avoid seismic (and possibly catastrophic) changes in the configuration.
– Never underestimate simple processes – They usually hide secret tasks, executors, approvers and usually are not so well defined. What is a simple form can become four weeks or more of design, development and testing.
– Never trust the sentence: “Don’t worry, we have all processes mapped out.” This sentence usually comes followed by another one, way over in the middle of the project: “Yes, well, here are the Visio files, but they’re outdated, so we will need to confirm all this”. Make sure all processes are really documented and that the documentation is up to date.
– Always show how the product to the final will probably look like to the end user before you start building – If the user is not ok with the console or portal or any other aspect of it, there will be confusion, lack of acceptance and more work to convince the users later.
– Beware of the Scope Creep – that is more of a general rule for any project, but since you’re handling automation and processes, there’s is always space for improvement and with improvement, and there will be lots of ideas. Which are good! But remember that you had a scope (time and money) for the project, so, try to accommodate those as phase 2, phase 3, etc.
– Make sure you have the right people with you to make the calls – if your main sponsor/decision maker is on vacation for two weeks in a critical phase of the project, make sure that whoever is in her/his place will understand all the consequences.
– Document – management packs can hold a lot of information and you can easily store things all together or in the wrong place. Be careful and document where you create them. You’ll need to know when you are moving from staging to production, when updating, etc. Documenting also means good naming conventions and clarity when naming objects, management packs, templates, groups, etc.
I hope these simple topics can help you with a better Service Manager project in the future. There are probably more, but I believe these are a good start.