Tag: ITSM

Project Management, A Process or Practice?

Is the work of project management a process or practice?

I think project management is both a work of process and practice, so what is the distinction?

A process focuses on being consistent and repeatable – you should be able to get predictable results from a process.

PMBOK has five process groups with ten knowledge areas intersecting those process groups for various project management stages.

Practice focuses on applying knowledge, judgment, and wisdom to achieve the desired outcome and dealing with changes. All project managers need to produce results by balancing the triple constraints: scope, time, and cost. Those constraints can often change during project execution.

A good project management practice established and executed by qualified personnel will bring the desired results, even with those limitations.

These days, just about everything we do requires a mix of process and practice. For example, implementing just the ITIL processes verbatim from the framework without applying the necessary effort on building an ITSM practice will just yield generalized, paper processes.

With the pace of changes picking up and the predictability of our environment shrinking, developing a practice is just as important as developing the required processes.

ITSM Tools Operation Continuity Plan – Part Two

We discussed the first several topics (scope, data considerations, and external dependencies) that should go into an ITSM tools operation continuity plan during a disaster recovery (DR) scenario. In this post, we will conclude the discussion by covering the people, procedures, checklist, and validation sections of the plan.

Recovery Team and Communication

The section spells out the key roles and the staff members who will be responsible for implementing the plan. It will include the typical information such as name, organization affiliation, location, and contact details. This section should also include agreed upon communication protocols for the duration of the recovery process. For example, teleconference bridge information could be something useful to include, if that is your organization’s standard practice. Also, if your organization has a major incident handling practice with standard communication and reporting requirements, you can cover the pertinent details within this section or at least make a reference to it.

Recovery Procedure and Configuration Details

This section outlines the recovery instructions and procedures with as many details as necessary for a successful recovery. This section also provides all configuration details that need to be in place in order for the recovery solution to work as designed. Just how much information do you really need to include in the document? I believe the level of detail will largely depend on whom your organization anticipate will execute the plan or heavily influenced by your organization’s disaster recovery plan.

By default, I would recommend having the level of detail based on the assumption that the people who will execute the plan are NOT the same folks who operate the production environment pre-disaster. This is the safer router in my opinion.

For example, your organization uses ITSM product XYZ, made by company ABC and operated by an off-shore team from vendor OPQ. When a disaster strikes your data center, the network connectivity between your data center and your production personnel from OPQ was cut off. At this time, your OPQ vendor has another team at a different location who can access the recovery site and knows your ITSM product. With a properly documented recovery plan with the right level of details, you can leverage your vendor’s second team quickly to start working on the recovery without any help from the production team.

Checklist of Key Actions or Milestones

To help everyone who needs to understand and execute the plan, I recommend having a section that outlines the key tasks and activities so no important activities will be missed. The checklist can also be used to show the various communication and escalation points.

Testing and Validation Steps

This section outlines the detailed testing strategy and validation activities required to implement the recovery plan. Similar to the recovery procedures section, it is highly recommended that these instructions are comprehensive, so the recovery solution can be fully tested by people who may not be the same team as your production crew. The section should also account for all potential conditions, events, and scenarios. The section should contain information that can be used during the testing such as:

What are the success criteria for the test objectives?
What are the assumptions defined for this test, if any?
When is the testing window?
How should the security setup be taken into consideration?
Which tool modules will be tested?
Who will be conducting the test?
What are the steps to validate the application and data integrity?

Return-To-Normal-Operation Procedure

This section describes the instructions/procedures necessary to return to the normal production environment once it has been restored. For this section, I would say probably the most key information to explain is how the data will be synchronized between the production and the DR systems. Again, the key objective is not to lose any data captured by the ITSM tools while it was operating in the DR setup. This section will also include the necessary testing and validation steps to ensure that the production system is back in full operation, so the DR system can be fully shut down and return to the stand-by mode.

An ITSM Tools Operation Continuity Plan Example

I hope this particular discussion on the ITSM tools continuity plan provides something of useful tidbits for your organization to think about and to plan for. Considering the importance of the data and transactions captured by the ITSM tools for many organizations, having a workable continuity plan is really not optional anymore. If you don’t have anything in place now, I recommend start small by drafting a plan and making the scope compact enough to cover just a few high probability and high impact scenarios. Work with someone within your IT organization who is responsible for the overall IT continuity plan, so your plan can integrate well with the overall IT and business objectives.

Conference Planning How-To and Examples

One of the events I look forward to every year, other than my mom’s birthday and the anniversary with my wife, is the ISACA Los Angeles Chapter Spring Conference. Every year around March or April, several hundred participants take part in this three-day get-together at Hilton Universal City. Over the years, we have provided our membership with solid programs that have delivered great education values. At the same time, the organization committee has had many wonderful individuals who volunteered their time and made the conference event as excellent as it is today.

I first got involved with the conference organizing committee back in 2001. It was a much simpler event to plan for back then but has since gotten more sophisticated over the years. Even with its growing sophistication, the conference is still being put on by a group of volunteers, not by professional conference event staff. I surmise when you have great leadership and dedicated volunteers within the organizing committee, anything is possible. That said, we are no professional event planners and everything happens in the conference is an opportunity to learn and to fine-tune. For those of you who are planning or thinking about planning similar events for your organizations, I have something that might help.

Generic_Example_Conference_Organizers_Manual

Generic_Example_Conference_Project_Plan

I have posted two documents on this blog that give an overview of what we have to do for this annual event. If you don’t have such documents in place and would like to refer to something to start with, these two documents together could be a decent starting point. I had to remove the proprietary information from the original planning documents but the resulting documents can still be helpful. Putting on a conference is a project, and the typical project management principles and planning discipline can only help.

I hope you will find these documents useful for your planning endeavors. If you have any questions about how we plan the event or would like discuss any planning aspect further, please feel free to leave your questions here or contact me directly.