9 Tips for Creating an IT Service Catalog

Why do you need an IT Service Catalog? Let’s count some of the ways.  A Service Catalog offers your organization an efficient tool you can use to:

  • Define and publish available services.
  • Standardize service fulfillment processes.
  • Establish achievable service levels.
  • Determine the associated costs to manage performance.

When the new catalog is in place, IT organizations can begin to operate as a business.  Services that are not frequently requested by customers can be discontinued, and delivery processes for high-volume services can be optimized. Key Performance Indicators (KPIs) provide greater visibility to control costs and respond to customer demand.

The following describes some crucial hints and tips for ensuring that you reap the benefits of successful service catalog implementation.

1. Pilot the Catalog

Determine which services and attributes need to be included or revised prior to comprehensive rollout. Publishing the initial service catalog without chargeback, targeting a specific business unit, or covering only a few primary IT services may allow for refinement and iterative maturity over time.

2. Establish Your Team

The initial catalog should be driven internally within IT, and should include adequate representation from all stakeholders within each domain to ensure that documented services are appropriate and valid. Executive sponsorship is also critical.

 3. Establish A Baseline

The team should create a list of all the services that IT offers, regardless if whether or not they will be included in the initial catalog of services. When creating the baseline catalog, it is important to consider the following key guidelines to ensure that services offered can be effectively managed moving forward:

  • The service is self-contained and is not part of a larger service offering.
  • The service can be monitored and measured for consumption levels.
  • The service has costs that may vary with changes in consumer behavior.
  • The business could potentially procure the service externally.

4. Refine Service Offerings

The initial baseline should be refined to include only those initial services to be included in the pilot or first iteration of the IT service catalog. If different levels of service will be provided, cost variations should be documented by consumption type.

5. Perform Service Benchmarks

Once services have been identified, service levels should be benchmarked using available monitoring capabilities and measurement techniques.

6. Publish the Service Catalog

After services are documented, reviewed, and finalized, the service catalog should be made available to the business, preferably through an appropriate business relationship manager.

7. Establish Service Agreement

Following business review and selection of services, any formal service selections and supporting agreements should be facilitated through the service level management process and documented in a standard Service Level Agreement (SLA).

8. Improve Services

Any service improvement initiative should be iterative in nature and should ensure that ongoing improvement activities enhance communication with the business. Maximize operational efficiencies and continue cost reductions through a continuous service improvement program (CSIP).

9. Refine the Service Catalog

The cost, complexity, and difficulty of implementing an IT service catalog will vary greatly depending on the details incorporated into the final document.

At the end of the day, Service Catalogs allow us to become more informed of customer desires as well as our offering potential.

Want to Create an IT Service Catalog for Your Company?

The dedicated team at The Art of Service has designed a step-by-step toolkit to aid any IT professional in the implementation of Service Catalog capabilities in any organization. The toolkit aims to introduce Service Catalog concepts, as well as provide you with the tools to successfully create a workable Service Catalog culture in your organization.  Click here and check it out!

 

Practical Advice for Preparing Your 2014 IT Budget — And Free Templates!

Let’s face it, friends.  Budgeting can be a real pain!

I’ve seen IT managers spend hours upon hours developing what they think is a concise budget and proudly deliver it to their manager thinking it is “accurate” and “what their manager wants” only to have it summarily rejected and sent back for a re-work. In other cases, I’ve known IT managers who spent countless hours developing an approved budget only to find themselves asking for more money four or five months into the year because their actual expenses are blowing out of their budget.

Preparing your annual IT budget does not have to be an ordeal. It can actually be simple and a rather quick process when you are prepared, know what to do, and you have tools to help.

Contrary to conventional wisdom, being accurate is not always your top priority when budgeting. Certainly, you want to have insight into the budget categories and have your estimates fall into the right “ballpark”, but you also need to be appropriately conservative and build the appropriate buffers into the numbers. The reason is simple:

Surprises Happen!

Not only do surprises happen, but those surprises are almost always costly surprises — seldom are they good surprises!

To help you organize your thought process around budgeting I have assembled the spreadsheets I have used in the past to prepare dozens of IT budgets for various businesses.  You can download all of my worksheets for free right here:

This download is free to all Toolkit Cafe Registered Members. Please login to download

Not Registered Yet? Click below to “Join Us At Toolkit Café”!

Register Button Blue

(Once you have logged in, return to this page and refresh your browser to access your free download)

While these worksheets will be quite helpful in helping you organize and plan your budget, I highly recommend you also take a MDE_IT-Budgeting-d-150x150quick hour or 2 and read through my concise eBook:  IT Budgeting:  Operational and Capital Budgeting Made Easy.  This book will reveal my practical secrets for creating a successful IT budget.  Using my methods, I have never missed a plan and now you can benefit from my insights.  Click here to download my book and add a little sanity to budget season!

Minimize downtime with Sisco’s free Move/Relocation Checklist

Here is a no brainer about the role of IT support : Our job is to keep the business “up and running.” That’s right, most of us in IT have a 24 X 7, 365-day obligation to keep our technologies running and our business clients positioned to use them. So who has time to move our offices or relocate a data center?

Sooner or later you are going to have to support a company move, department relocation, or opening up a new office. The very nature of these activities suggests downtime, and downtime is an IT organization’s worst enemy.

Getting a move on (and we don’t mean twerking)

A move or relocation is a project just like any other project, and one of the things you want to do is to minimize the business impact in achieving your goal of getting the affected organization and people in place so they can be productive.

I was the CIO of a company in the mid-90’s that grew from $30 million in revenue to over $600 million in just over 5 years. We accomplished much of this growth by acquiring other companies that provided the same type of physician billing services we provided. Many times we would acquire a company that had an office right around the corner from one of our offices. To leverage our investment we either consolidated the two offices into one of them or moved both offices to a brand new location.

It seemed like we were moving a group of people to a new location or opening up a new office every week.

Relocation activities create lots of opportunity for downtime and loss of productivity. Downtime was a huge cash flow and client satisfaction problem in this industry.  If our employees could not bill and produce insurance claims and collect the money for physician services, our physician clients didn’t get paid, and neither did we.  Minimizing downtime was a key objective because our operational and financial success depended upon it.

Introducing the Office Move/Relocation Checklist

To help us manage an office move, we developed a simple Office Move/Relocation Checklist.   This checklist can help you with almost anything that you need to do from time to time, things like:

– Office moves
-Delivering classes
-Deploying equipment
-Troubleshooting specific technologies

In this particular example, there are three key sections:

  1. Move preparation tasks that include a responsibility and completion timeframe
  2. Day of Move tasks you should target
  3. List of equipment you need to support the move

Checklists like this one and others we used helped our IT organization minimize downtime and disruption to our business by completing our projects reliably and consistently, key ingredients for a positive IT support operation.

Download the Checklist for Free!

This download is free to all Toolkit Cafe Registered Members. Please login to download

Not Registered Yet? Click below to “Join Us At Toolkit Café”!

Register Button Blue

(Once you have logged in, return to this page and refresh your browser to access your free download)

Check out Mike’s IT Manager Toolkit

If you like the Office Move/Relocation Checklist, you’ll be interested in the 100 tools and templates in the IT Manager ToolKit. To learn more about the complete IT Manager Toolkit, click here.  If you want to learn more about all MDE products and services, click here.

Mike Sisco is the President of MDE Enterprises, Inc., an IT manager training company focused on, “helping IT managers of the world achieve more success”. MDE resources are available at http://itmanagerstore.com

Your feedback welcome!

Thanks for visiting ToolkitCafé. To give feedback on this article, please post a comment below or email the editor.

5 More Critical Insights for Implementing ERP

In part I of this series on ERP, we interviewed Brian Schaffner about five of the things he wishes he’d known before he started implementing his first ERP solution. This week, our interview continues with five more lessons for CIOs, IT directors, and IT managers who are staring down the gullet of an ERP implementation deadline.

ToolTalkWeekly:  Testing an ERP may take as long, or longer, than to do the development and configuration

Brian Schaffner: During a typical software lifecycle, you perform rigorous testing of the solution to be sure it meets your requirements and does what you need it to do. On smaller scale systems, you can often predict the testing effort using various formulas and rules of thumb. With an ERP implementation, however, the rules can be different.

Because an ERP system usually supports many more processes than a smaller, more focused system, and because the processes within the ERP are more integrated – there can be many more dynamics at work than in a typical software solution. As a result, the number of permutations that can arise grows exponentially as you define and build the system. You will need to think about the effort required to test and validate all of these variations. Automated testing solutions can be a tremendous help in this area, as you will need to not only test the system during the initial development and deployment, but will also need to regression test it as you make changes.

TTW: Implementing a system-wide ERP platform is a huge cultural change for an organization

BS:  As with overlooking your customers – some organizations overlook their internal people and culture when implementing a solution of this magnitude. Change is difficult for many people – and especially for organizations where there is an ingrained culture. Culture can take many forms – and in this case can be affected by changes in the roles that people have, in the tasks and processes they carry out, the skills required, and even whether their job exists after the system is in place.

It’s important to understand how the process of implementing the new system, and how the operational rollout of it will affect the organization as a whole. You don’t want everyone to come in on a Monday morning and have a crash course on how to deal with the system, customers who are complaining and anything else that’s going wrong. This can be addressed partially through normal training curriculums which train users on how to perform specific functions within the system. Usually, though, that’s not enough. You should also think about how you will transition into the new system and how you will socialize those changes – organization-wide. You’ll want to make sure that the non-IT people understand that the new system isn’t going to be perfect – and will definitely have issues. As the organization learns about the changes, and adapts to them over time, the process of adopting the new system will go much smoother.

TTW:  The cost to implement an ERP are probably 2x to 10x whatever you think the initial estimate is

BS:  IT news sources have no shortage of stories of failed and expensive ERP implementations. So – you probably already know this one, but it bears repeating. Your ERP will cost significantly more than you are planning. Very few ERP implementations cost anywhere near the initial plan.

You should go in expecting to spend between 2 and 10 times your initial cost plan. This may seem like too much – and possibly there are ways to reel in the costs. The reality, however, is that ERP systems are complex and planning them out in a way that’s accurate is very difficult to achieve. That complexity often comes from many of the issues listed above, such as the ERP doesn’t fit your business processes, so you pay extra to customize it (or your processes) so that they match. Or maybe your business process requirements are all in the head of the mainframe programmer that retired last year, and now you need to pay a hefty consulting fee to bring him back to help you. Perhaps you thought you were going to have a 1 year, big-bang implementation – but half-way through you realize that a 3-year phased plan is much easier for the organization to consume. Some of these you can plan up-front – but many of them are hard to predict until you are already in the middle of the project.

TTW:  ERPs are long cycle projects – and they take a heavy toll on the IT team and the business users

BS: Most ERP projects take 12 months or longer to complete. That can be a long time for everyone involved to continually keep focus and motivation. The IT team often has some idea of the impact coming their way when they sign up for a project like this. IT groups are usually familiar with the process of system development and implementation, and have grown accustomed to the steps and timeframes involved.

Business users, on the other hand, are usually in a different boat. Many non-ERP projects that involve business users only require limited involvement and input. During an ERP implementation, the demand on the business users can be very high. At times, the business users will work as many or more hours than the IT team – helping to articulate their processes and how they work, helping to test and verify that the system does what it’s supposed to do, and even participating in and leading training of their departments. All of that effort can be a drag on their morale, and also a major impact to their normal daily duties.

TTW:  A clear understanding of the benefits is crucial to prioritizing the work, and to measuring the success of the project.

BS: Many ERP implementations start off with a grand vision of how great things will be when the project is over and everyone is reaping the benefits of a great implementation. What usually happens over time is that trade-offs and compromises are made in order to keep the project schedule on track and keep the costs in line. When that happens, the goals and benefits of the project can erode.

A clear understanding of the benefits and priorities can and should be the backbone of decision making when reviewing costs, schedules, and other project risks. It’s understandable to back off of certain features because they are going to take too much time or effort to implement; but if not implementing the feature compromises a core benefit of the system, it’s important to understand that when it occurs, not when the project is completed and the CFO doesn’t understand why the ROI doesn’t match expectations.

What’s your take on ERP?

To share your experiences with ERP implementations, please post a comment below or send a note to the editor.

Featured Toolkit: IT Project Management

If you’re looking for a great set of templates and tools for implementing an ERP solution in your shop, check out The IT Project Manager’s Toolkit.

Pat Vickers, Expert in Help Desk Management

7 Things a Help Desk Analyst Needs From the Help desk manager

Good support techs are hard to find and even harder to keep. It’s a tough and often thankless job. Callers often abuse them, other IT employees take them for granted and the hours can be terrible. More importantly, the combination of being able to understand the technology and work with people is exceptional.  There isn’t much a help desk manager can do about those things. What a manger can do is ensure the analysts have everything they need to do their job to the best of their ability.

     1. The right tools

No job is easy without the right tools. Whether the job is to repair plumbing, cook a great meal or diagnose a computer problem, having the right tools is essential. For a help desk the right tools are;

a)      Schematics on all supported hardware

b)      Good remote control tool

c)       Documentation on all supported software

d)      Admin rights to every supported system

  1. Appreciation for a job well done

Award ceremonies can be fun but giving out the same plaques every year or month isn’t true appreciation. The way appreciation is properly shown is to personally thank the employee. Managers should occasionally stop by the desk of someone who has done well, maybe even invite that employee out to lunch. While there the manager should thank the employee and be specific about why that employee is appreciated. A follow up email that can be kept for their records is a nice touch but the personal visit will stay with the employee for weeks.

  1. Training

Nothing changes faster than technology and the Help Desk analyst must be at least one step ahead of callers every day. Whether in a classroom, book or computer based. Training for the Help Desk analyst is essential. Of course time and money are always an issue. Anticipate and plan for slow periods by keeping up to date training programs available. Even if only for an hour, taking advantage of low call volume to increase skills is the best possible use of a Help Desk analysts time.

  1. Help in the trenches

Most Help Desk managers spent quite enough time on the phone, before they were promoted, and have no intention of going back. This is a mistake. While a manager’s time is best spent managing, the occasional foray back to the trenches not only keeps him or her sharp and in the game. More importantly, the extra help on a really busy day will be greatly appreciated by the analysts. It’s always good to know the boss can do the job and not just boss.

  1. Trust

Trust can be the toughest thing for any manager to give. For one thing, some employees just don’t deserve it. Most do and they should be left alone to do their job. Whenever possible a manager should deliver the requirements and then let the analysts figure out the best way to deliver. Micromanaging by scripting or insisting information be gathered in specific order are indications of mistrust and make an analysts job, more difficult, not less. New employees or those who aren’t performing need those things. Give the rest the room they need to do their jobs.

  1. Reasonable Requirements.

Reasonable requirements vary from office to office, depending on what is supported and the sophistication level of the users. It’s impossible for anyone outside to say what is reasonable and what isn’t.  Looking at history and working with trusted employees is the only way set the parameters. Once those parameters are set the expectations shouldn’t be raised, without serious reevaluation. In other words, once an employee has reached a productivity level considered excellent, stop raising the bar. Doing so just forces the employee to have a bad month, in order to start all over again.

  1. Occasional off the phone work

A help desk analyst should spend the vast majority of work time, on the phone.  The most important tasks on any help desk are answering the calls and helping the callers. Everything else is secondary. There are some tasks that are not phone related and giving analysts time on those tasks, when call volume permits, is a great way to recharge batteries. Examples are giving training as well as receiving it, documenting procedures and testing new software and hardware.

These seven things are important, doable and make a difference. There is more though. Tell us what you need from your manager and why?

For more great information on how to manage your IT employees check out The Practical IT Manager Gold Series by Mike Sisco. It’s an great resource.

5 Critical Insights for Implementing ERP

Oh, Enterprise Resource Planning (ERP), you promise so much but you’re a fickle consort. That’s the lesson we learned when we interviewed Brian Schaffner, Director of Enterprise Architecture and Infrastructure for a healthcare provider with operations on five continents.  Brian has worked and lived through his fair share of ERP implementations in companies of various sizes and industries. Whether you’re considering your first ERP implementation or you’ve been charged with upgrading an existing ERP integration, you can benefit from Brian’s mistakes as he shares the things he wishes he’d known before he started with ERP.

If only I’d known then what I know now about ERP

ToolTalkWeekly: You said the first thing you wish you’d known before you started your first ERP implementation was that not all ERP solutions are the same.

Brian Schaffner:  Some ERP vendors cater to specific industries, some and are more flexible, and some are too big or too small for your company. It’s not always easy picking a solution that fits your company and its needs. Evaluate companies by looking at their track record with companies or organizations that are similar to yours. If you are a mid-size state college – look for solutions that have done that before. You don’t want to be a vendor’s guinea pig when implementing a system of this scale.

TTW:  What if you’re migrating from an existing system to a new system?

BS:  You and your team need knowledge and documentation of the existing system. That’s key.This probably sounds like an obvious statement, but it’s surprising how many organizations have either no documentation, or the documentation they do have is nearly useless. That can be true of knowledge within the organization as well. Systems that have been around a while often evolve from what the documentation says they do. The people who know what the system does, and, more importantly, how it works – have moved on or retired.

Before you embark on your ERP quest, take inventory of what you know about your existing business, processes, and systems. You may find that you are fully staffed, documented, and knowledgeable. However, if you are like most companies, as you uncover the rocks, you are more likely to find snakes than gold. It’s important to know what you know before you get started, because once you start implementing it’s much more difficult to go back to the beginning.

TTW:  What’s a typical timeline look like for an ERP implementation?

BS:  Depending on the size of the system and company – phasing or building integration may be better than “big bang.”Many ERP vendors have solutions that will handle many, if not most or all, of your processes. This can be great for streamlining your organization and providing better service to your customers. If you are a small organization, you may be able to consume all of the changes to all of those processes in a single implementation. Most organizations, however, struggle to implement using the “big bang” – or all-at-once approach.

If you find your organization overwhelmed by the magnitude and quantity of changes taking place, look at ways to phase the implementation. Start with more simple, back-end processes like Accounts Receivable, Accounts Payable, and General Ledger. Often, those processes form the backbone of an ERP implementation – and often they are not overly customized. Many times, these are easier to implement and integrate with.

Once you have the core system running, you can build integration layers that handle getting data in to, and out of, the system. Modern integration platforms provide not only batch data loads, but also real-time messaging and synchronization across systems.
ERPorNot

TTW:  IT people tend to think in terms of impact on IT functions and internal business operations.  What’s the impact on customers?

BS:  If there are customer-facing pieces of your project – communicate a lot and often with customers.  A huge mistake that companies make when implementing new internal systems is forgetting about the external impact. Usually this means customers – but can also mean vendors, financial institutions, investors, and others who interact with you. Customers, in particular, can be affected in many ways. For example, if you change the format of your invoices – and customers have processes that depend on the invoice format – you probably just broke their process. A new system also means bugs and bumpy processes. Customers understand these issues if they know what’s going on – but if you don’t tell them, and they simply experience the issues themselves, they are likely to become frustrated or leave.

Involve your customers, and other external entities in your project. Tell them what you are doing, why you are doing it, and how they will benefit from it. If you have target dates where they will experience changes, let them know in advance. The more you let them know what’s going on, the better prepared they will be for the changes, and the more successful you will be in the implementation.

TTW:  Is ERP an inevitable part of IT operations?

BS:  An ERP platform does not constitute a holistic architecture.  Sometimes when you implement a new, integrated system – the new system brings its own technology, platform, framework, and architecture. Usually those are all necessary to make all the pieces of the ERP work together in harmony. In the context of the ERP system, that is all well and good. For many organizations, however, the ERP is not the boundary of their systems. Sometimes you have customizations or proprietary systems that need to integrate, or possibly be built into the ERP system. It can be tempting to adopt the technology, platform, and architecture of the ERP for these auxiliary systems.

Before you do that – you should consider the implications. As the ERP architecture evolves – are you willing to invest in evolving all of the systems that are based on the ERP architecture? Or are you willing to wait for ERP enhancements as you bring all of your systems up to date? There may be operational considerations as well. For example, with some systems you may have monolithic components that require the entire system to be down during maintenance. If you understand these types of implications, and can live with them, you may be okay. If not – you may need to consider other ways to design the auxiliary components.

Part 2: Five more lessons you need before you implement  ERP

Follow the discussion when we continue our interview with Brian he talks about what happens after you select an ERP solution. In the meantime, please tell us what you thought about this content by posting a comment below or email the editor.

Featured Toolkit: IT Project Management

If you’re looking for a great set of templates and tools for implementing an ERP solution in your shop, check out The IT Project Manager’s Toolkit.

Will Knowledge Management become the core of all IT frameworks?

What is knowledge management, and why should IT managers, directors, and CIOs care? In this column, I’ll define knowledge management and explain how it fits into your IT framework.

Defining Knowledge Management in the IT world

The discipline of Knowledge Management is simply a means of focusing one’s effort in the right direction. In order to gain a better understanding of Knowledge Management, let’s take a quick look at some of the more obvious business benefits:

  • Improves decision-making capabilities; the right knowledge is available to the right people at the right time.
  • Reduces research time and training through the provision of a knowledge framework.
  • Stimulates cultural change and enhances employee retention.
  • Streamlines and increases production speed and reduces costs.
  • Improves customer service and reduces response time.

How are Knowledge Management and the IT framework compatible companions?

The rapidly growing trend of IT management has truly begun to stamp its authority in the corporate world, with no sign of defeat. Organizations are actively implementing a variety of IT-related services, processes, and strategies in order to keep up with industry competitors and to ensure that profitability steadily rises. Besides its indisputable popularity, what precisely is it about IT that has us all on the edge of our seats? It could be argued that IT is simply a plethora of communication media or a technical service. However, a true believer would retort that IT abilities not only generate entire business approaches, but also assist in creating business goals and objectives.

Knowledge management can often be perceived as the definitive objective of centralization of an organization. IT services and processes themselves are considered to be categorized under a centralized management or power of authority model. Similarly, knowledge management makes it possible to approach the business model from a central point of view. The benefit of implementing knowledge management is that its processes deal directly with producing competencies which branch out to all business levels.

Applying knowledge management to IT functions

For many organizations, this particular benefit of knowledge management can be applied to IT functions, indicating that IT can effortlessly be considered a secondary process of knowledge management. Providing knowledge management endeavors to extort predictions from an organization’s abilities, as well as record vital information (recent and historical data), making it highly feasible for IT to submit to its authority at some point.

Countless predictions have been made regarding the future influence that knowledge management has over IT resources. One possibility concludes that businesses will incorporate knowledge management into their IT framework; another foretells that knowledge management will still happily co-exist with the IT department, all the while sitting pretty on a rung above IT on the business management ladder.

We watch with anticipation as existing IT methods, capabilities, and devices evolve beyond our wildest imaginations. It is through these advancements that knowledge management could very well be a valuable tool for many businesses that are looking to effectively control IT processes and goals.

Every organization seeks to improve its foundation of knowledge. The dedicated team at The Art of Service has designed a step-by-step toolkit KM Toolkit_boxshotto aid any IT professional in the implementation of knowledge management. The toolkit aims to introduce knowledge management concepts, and provide you with the tools to successfully create a workable knowledge management culture in your organization.

Click here to learn more about Art of Service’s Knowledge Management Toolkit!

What’s your take?

To share your thoughts on knowledge management, please post a comment below or email the editor.

3 golden rules of IT vendor management

Got vendors? You need vendor management. As an IT manager, you spend a lot of your company’s money. You hire individual consultants and big-time corporate consultants.  You sign Statements of Work or multi-year agreements  with niche- and enterprise-software vendors. You pay big bucks for professional services provided and software and hardware maintenance contracts.

So how do you manage those precious, vital third-party service providers? More specifically, how do you make sure you’re getting what you think you’re paying for? Here are three golden rules of IT vendor management.

1. Do your due diligence before signing a contract.

Do not be fooled by a sweet deal that’s only good until the end of the quarter.  If a vendor tells you that prices will go up if you don’t sign the contract by the end of the quarter, tell that vendor to go fly a kite. Smart IT managers perform due diligence on third parties that’s commensurate with the risk the third party brings to the company.  Here are a few key questions to ask before you enter into a written agreement with any third party whose products or services are mission-critical to your company. (a) Does the vendor have experience in this area? (b) Can the vendor afford to take on our contract? Hint: If the vendor is waiting on your first contract payment to hire the programmers needed to do your project, you’re working with the wrong vendor. (c) Has the agreement between your company and the vendor been reviewed by your company’s senior managers and the departments that will be affected by bringing on this third party, like internal audit, legal, and operations?

2. Monitor the vendor’s performance.

Before you sign a contract to engage a vendor to provide services, ask yourself this question, punk: How will you know if the vendor is doing what you’re paying it to do? If there’s a project plan, is someone making sure deadlines are met? If the vendor’s work is ongoing, who is making sure that (a) invoices match actual work performed? and (b) is the vendor meeting its service level agreements as defined in the Contract or Statement of Work?

3. If the vendor craters, have a plan.

This third “golden rule” is to remind smart IT managers never, ever to assume that even the biggest and best vendors are infallible. As part of your due diligence process when you’re onboarding a new third party or engaging in a new project with an existing third-party relationship, make a D.R. plan. Require the third party to tell you how long it will take THEM to recover if they have a disaster. On your side, make a plan for what you’ll do if the vendor has a disaster that lasts longer than your business operation can tolerate.

Do you worry about IT vendor management?

If you liked these “golden rules,” please post a comment below or send an email to the author or post a comment below.

Is a third party helping you with a system conversion?

If you’re working with a third party on a system conversion, you can incorporate these three “golden rules” of IT vendor management into yo8ur project plan.  Use this link to download Toolkit Cafe contributing author Mike Sisco’s free Systems Conversion Project Template.

This download is free to all Toolkit Cafe Registered Members. Please login to download

Not Registered Yet? Click below to “Join Us At Toolkit Café”!

Register Button Blue

(Once you have logged in, return to this page and refresh your browser to access your free download)

How to Implement an IT Systems Conversion Project Schedule

In my last post, I showed you how a simple Project Schedule Template can save time and headaches for IT managers. If you are in IT, sooner or later you are going to need to convert some technology, install new hardware and software to replace some old equipment and software, or maybe install new equipment and software for a totally new application. In this post, I’ll show you how to use my time-tested Systems Conversion Project Schedule.

Schedule the work, work the schedule

In most system conversions or new system installations, there are a few key groups of tasks required to do the job. One thing you can to do  help organize your project schedule is to group the detail tasks by category.

In the sample I’ll discuss, I identified  six major categories of tasks:

  1. Assessment – Identifying everything required to complete the project.
  2. Order and organize – Ordering equipment, software and other items as needed plus organizing components of the project.
  3. Infrastructure – Infrastructure and desktop support tasks.
  4. Setup/Installation – Software installations, etc. File build tasks would also be in this category.
  5. Programming – Programming and Business Analyst work.
  6. Training – Training and testing tasks.

You may need other category groups, depending upon the nature of your project. Most system conversion or installation projects will have at least the six that I’ve listed above.

Organizing the tasks by category group will also help you when you run weekly status meetings to determine the status of the project as it organizes the discussion into logical work groupings.

“X” marks the spot!

What I like to do for each task is to put a “/” in the cell for the week the task needs to be completed by. When the task is completed, I change the slash (/) to an “X”. This way, it is very easy to walk through a status meeting quickly by just focusing on this week’s tasks that have not been marked as completed. It also makes it easy to visually see the status of the project.

Another thing to consider for your project is that there will be tasks that are critical to the project.  In fact, those “critical tasks” may turn into  bottlenecks that can jeopardize a successful delivery of the project. It’s easy to highlight these tasks for the team by shading the cell that shows the scheduled completion date for the task. By doing so, that shading will trigger you to ask about the status of the task weeks in advance of its scheduled completion date, and you can  instill a sense of urgency on the parts of the people responsible for getting the work done.

Project success is much more likely when you organize your project into a solid schedule, assign appropriate responsibility, and check on the status every week.

In the sample there is a generic project schedule along with an actual project schedule sample used for a past systems conversion. Feel free to use these to help you in your next systems conversion or installation.

Sisco6

Download Mike’s IT Systems Conversion Project Template!

This download is free to all Toolkit Cafe Registered Members. Please login to download

Not Registered Yet? Click below to “Join Us At Toolkit Café”!

Register Button Blue

(Once you have logged in, return to this page and refresh your browser to access your free download)

 

A simple project planning tool that will save you countless headaches

What do you think of when you hear the word “management tools?” Soft skills like “ability to listen well?” Software tools like compilers and debuggers?  In this column, I’ll tell you about one of the  management tools I have used the most in my long career: a simple project scheduling template.

Background: Project Management 101

I was first introduced to what we now call “project management” years before there really was such a term called project management. Believe it or not, in the early days of IT we didn’t have project management methodologies, nice tools, or training. Today, project management resources are everywhere.project schedule template

When I first joined IBM in 1976, my Systems Engineer (SE) responsibility was to support existing clients with IBM computers and install new IBM computer systems, usually for small businesses who had purchased their first computer. We called it the “mini-computer” era. It was exciting and lots of fun helping small business owners automate part of their business.

We didn’t have laptops, no software to speak of for personal use – not even project management software. What we did have was a predefined form and a pencil along with knowledge of the tasks required to install a new computer system plus the business applications that went with it.

IBM trained me on their installation process. We didn’t call it project management, but that’s certainly what it was. With this training, IBM provided a blank installation scheduling form (template) by which we could develop an installation schedule for each new client.

30 years later

The process we used to install computer systems in the late 70s and 80s is exactly the same process we use today. You need a project schedule that includes a few basic things like:

–       Tasks required to do the job

–       Responsibility assignment for each task

–       Timeframe for completing each task

IBM gave me a form and a set of standards (tasks required to do the job) so I developed an installation plan, or schedule, for each new computer system I needed to install.  I used the schedule to manage the project, just like we use the Work Breakdown Structure (WBS)  today.

Of course, in my IBM days, it was all manual with paper and pencils, so it was smart to have a good eraser close by.

When the PC came out in the early 1980s along with VISICALC, I put this paper form onto a spreadsheet. (I wonder how many people reading this article remember VISICALC, the first spreadsheet application.) It revolutionized much of the manual and tedious administrative work we used to do with pencil and paper that we now take for granted.

I still use this template in Excel spreadsheet format to manage projects. Even though I’m well versed in Microsoft Project, I always revert back to my simple project schedule spreadsheet template whenever I can. For me, it’s just quicker and easier to use and it works just fine in providing what I need to manage a project.

Simple tools work just fine, and you won’t find a simpler tool than this Project Schedule Template.

Download the Project Schedule Template for Free!

This download is free to all Toolkit Cafe Registered Members. Please login to download

Not Registered Yet? Click below to “Join Us At Toolkit Café”!

Register Button Blue

(Once you have logged in, return to this page and refresh your browser to access your free download)

Talk back to ToolTalk Weekly

To comment on this column, or to tell us what you think of the free Project Schedule Template, please post a comment below.