Tag: Planning

Career Planning Model

One endeavor I took on earlier this month and glad I did was being a mentor for the Ascend USC Student Chapter. Each mentor gets grouped up with three undergraduate students along with another junior student mentor. Together all five of us meet as a group three times during the 10-week mentoring period, along with opportunities to have one-on-one between the students and the mentors during the same period.

One question that gets asked frequently by the students and probably being one of the main reasons why students seek out mentorship is the age old “What should I do after I graduate?” Or asked the other way around, “What do you want to do when you grow up?”

As a parent, I have hope and aspiration for my own children, but I also recognize this is a question that only the individually can truly answer. I, like the students when I was young, asked the same question multiple times while growing up, and still ask the same question from time to time. Personally, I have adopted a career planning model to help with this particular decision making process. I had talked about this model before with my children, so I presented the same model to the student mentees as well. It is a simplistic model of triangle with three basic considerations as the end points. (see the page 1 illustration in the PDF file)

The principle goes like this. I believe a viable career choice is a something that balances the “pull” or “reach” by the following three considerations. The basic considerations are:

Talent: What are you good at doing? This is where your education, training, skills, and experience acquired all come into the consideration.
Passion: What do you like to do? Your interests, aspirations, dreams, etc. What stuff motivates you? What r would you rather do when you have the time?
Market: Who might pay you to do what you would like to do? Is there a market for the stuff you would like to or want to do? Is it financially rewarding or even viable enough?

I believe the job or career choices for most people will end up somewhere within the triangle due to those three basic considerations. Having a job or career that covers just one single consideration without addressing the other two is not practical for most of us. Having just two out of three considerations covered is doable but I think it usually results in a less than satisfactory job/career experience. For example,

• Situation One: Having just #1 and #2: Not economically viable unless you are financially independent enough. For most people I know, hobbies usually fall into this category.

• Situation Two: Having just #1 and #3: If your skill level is not there to maintain a certain base level of performance, you may not last very long on a particular job or in a career.

• Situation Three: Having just #2 and #3: If you don’t have some, minimum level of passion for what you do, the work itself is still worth doing but you may not be as aspired. Then again, it does the pay the bills.

When I explained this model to my children, one of them asked… What happens when people change jobs? Is it because of one of these three situations. Probably, but people also change jobs for a number of other reasons such as problems with the work environment, with the co-workers, or with the boss. This model cannot address those external factors just yet.

Another question came up was… Is this the only triangle where I will be confined to work with? How would I do something bigger and better down the road? Well, I think you will always need to work with these three constraints, but you will have more choices to work with as you become more experienced. As we grow older and acquire more experience, our own triangle expands as well (see page 2 of the PDF file). We will have more “room” to work with or have more job/career options as we expand the triangle.

Of course this is not the only or the best model of its kind. It is my own view of the reality. However, it is nice to know someone else also talks about a similar model – pretty cool.

Problem Management Process Design – Part 1

This is the first post of a series where we do the tutorial and some deep-dive of problem management (PM) process design. In this post, we will go over some of the process design considerations, such as the goals/purposes, the intended scope, problem prioritization, and roles and responsibilities. In the subsequent posts, we will go into more of the execution topics such as data capturing, process flows, as well as metrics and measurements.

Goal and Purpose of Problem Management

When designing an ITSM process, one of the most fundamental questions to ask is whether you need a particular process for your organization. By ITIL’s definition, a ‘problem’ is a cause of one more incidents. By managing problems, we are attempting to manage how we document, diagnose, and learn from the root causes after handling the incidents. Do most organizations need a problem management process of their own? I believe so. Even though most organizations may not have a formal problem management process defined, the act of diagnosing and finding root causes is practiced universally. Having a well-thought-out and documented process for root cause analysis can only help to strengthen the organization’s learning and knowledge management effort.

Scope and Policy Implication

In defining your problem management process, it will be useful to define a few scope or policy related items upfront. For example:

What organizational boundaries will the PM process be applicable to? Who can initiate, undertake, and/or authorize the PM activities? Like implementing most ITSM processes, the benefits will compound when everyone is adopting the unified approach and vocabulary. If you need to share the root cause data between organizations, it will be important to define the process scope beforehand.
Will all incidents receive the PM treatment? If you don’t plan to run all incidents through the PM process, what criteria will you use to decide which incidents to focus the PM effort on? Depending on the number of incidents you receive, practicing PM on every single incident may not be feasible, so you may need to be selective. Some organizations will initiate the PM process for incidents that meet certain criteria based on the incident priority (impact vs. urgency), the nature or category of the incident, the business segment affected, or some other factors.
It will also be useful to define what are some of the connecting processes to PM. Incidents, problem, and changes are typically closely tied to one another. What processes will trigger the PM process from upstream or receive the PM output downstream? Will your organization perform PM without having an incident? It is possible if you practice some type of proactive PM. Will all changes related to a problem be required to go through the change management process? Will the incident tickets, problem records, known errors, and requests for change be linked in some fashion? These are some governance related questions that will affect how you design the PM process.

Problem Categorization and Prioritization

When designing a categorization scheme for problems, I recommend using the same categorization for PM and for Incident Management. Having a consistent categorization for both problems and incidents will make designing, generating, and analyzing reports much easier. Some organizations use two separate categorization schemes for incidents and problems – a decision sometimes influenced by the tools. I personally think that is making things more difficult than it needs to be.

Prioritizing problems can help you focus your RCA efforts on problems that need the most attention. When prioritizing incidents, many organizations take the impact to the business community and urgency into consideration. For problems, I believe those two considerations are essential, and I would suggest adding two additional considerations into your problem prioritization matrix. The first one is the frequency of the incident. I think the higher frequency of the incidents; the higher priority should be assigned to problem. Also, the potential risk of not addressing the problems should also be taken into account.

Roles & Responsibilities

A PM process can involve a number of participants. Here are some typical roles to be factored into the design.

Requester: Who can initiate a PM exercise? How will the requester participate in the overall PM process
Problem Management Process Owner: The process owner ensures that the process is defined, documented, maintained, and communicated at all levels within the organization. The process owner is not necessarily the one doing the actual work but the process ownership comes with the accountability of ensuring a certain level of quality for the process execution.
Problem Manager: The problem manager is the main actor in the PM process and has the overall responsibility of implementing the PM process end to end, according to the process laid out by the process owner. The problem manager is also responsible for meeting the service level targets and reporting the metrics to the process owner for quality assurance purposes.
Problem Assignee: The problem assignee role is often played by the subject matter experts who does the actual RCA work and determine what the final root cause is. The problem assignee can also be assigned to ensure all changes get properly executed through the Change Management process.
Stakeholder: There could be several different types of stakeholders involved in PM exercise. At a minimum, the PM process needs at least one key stakeholder who can approve the handling of the problem records and the closure of the problems. The stakeholder could also act in a governing or mediation capacity when conflicts arise.

In summary, we just went over some of the planning elements for the PM process. We talked about why we want to PM in the first place, the scope of the process, how we categorize and prioritize problems, and the essential roles for executing the process. On the next post, we will go over the process flow and spell out more details for the PM activities.

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.

DIY Process Assessment Planning – Assessment Model, Schedule and Deliverables, Risks and Constraints

In the previous post, we discussed some process assessment planning considerations such as the problem definition, the scope (both organizationally and process-wise), and the analysis of the stakeholders. In this post, we continue and conclude the discussion with additional planning considerations on the assessment model, the schedule and deliverables, as well as the risks and constraints.

Assessment Model (Best Practices, Evaluation Process Integration, Organizational Context)

Using the information resources mentioned previously such as ITIL, COBIT, CMMI/ISO 15504, and ISO 20000, hopefully you would have constructed the best practice models and evaluation criteria to assess the processes and organization in scope. While an assessment spends a great deal of its effort in benchmarking and answering the question “Where are we now?”, it is just as important to start thinking and formulating the response for the question of “Where do we want to be?” In addition to coming up with the best practice model for the processes you plan to assess, I think it is also important to think about and include the following criteria into your assessment model.

Integration between Processes: These days, the ITSM processes rarely get executed effectively in total isolation. The processes often need to inter-operate effectively with other related processes in order to gain a certain level of maturity. For example, I will be surprised to see a high level of maturity for the availability and capacity management processes, if the change management process has been determined to be weak in the same organization. For the processes you plan to assess, be sure to take additional inter-process relationships into account and assess the process effectiveness truly end-to-end.
Organization Considerations: While understanding how mature of a process is and where you can improve is important, it is just as important to understand how the maturity score fit into the overall organizational context. For example, if the problem management process has been assessed to be highly mature but the organization places only a light importance on the process, the good maturity score will have only a limited significance. Hopefully from the problem definition exercise, you have already discovered what is really important to the organization so you can target your improvement plan accordingly.
Benchmarking and Comparison: Benchmarking is the way to compare how your organization is doing relative to other similar organizations or environments. In-depth benchmarking data are often not readily available and something that is a value-add feature when you utilizing external consulting for the assessment. For DIY assessment effort, you may or may not feel compelled to compare your results to other similar organizations, depending on your problem definition. At the minimum, the assessment results can always serve as the baseline for you to compare to when you perform another assessment in the future.

Schedule and Deliverables

Just like any project worthy of an organization’s time and effort, the assessment effort should be run and managed like a formal project. The schedule and deliverables should be carefully planned and spelled out during the planning phase. Because the assessment will likely require participation from a broad array of departments and individuals, being able to communicate the timeline (of what will happen when and with whom) is something the sponsor and participants should expect to have upfront.

When constructing the schedule or formulating the deliverables, keep the following in mind as you plan:

What assessment techniques do you plan to deploy to gather the data? Will you use questionnaires or surveys? Workshops or focus groups? One-on-one interviews? Or a combination of two or more techniques?
The project should have a firm start date and an end date, with clearly identified milestones. The milestones should include at least the kick-off event, the beginning, reminder, and closing dates for the survey, as well as the presentation date.
Identify all potential meetings and schedule them in advance as much as possible. The assessment project will involve a lot of meeting invitations, attendee tracking, and calendar management activities.
Formulate a communication strategy and start laying out various communication artifacts and templates that will be used to target various stakeholders and roles within the project.
Identify the ITSM education needs and account for the workshops and training classes in the schedule. For most stakeholders such as the sponsor and survey participants, the ITIL Foundation level knowledge or awareness could be sufficient. For certain key participants who may need to provide more specialized information for the assessment, ITIL Intermediate level knowledge maybe necessary. For the assessor (you this case since we are talking about DIY) or anyone helping the assessor in constructing the surveys and analyzing the results, advanced understanding of ITIL and how various processes fit with one another will be required in order to perform the assessment tasks effectively.

Risks and Constraints (Time, Resources, Tools, Politics)

The assessment team should also identify any constraints or risks that could materially impact the assessment, negatively or positively. One typical constraint/risk is the key participants’ schedule and availability during the assessment phase. Considering the assessment’s results are heavily dependent of the quality and quantity of the input provided by the participants, not having the people you need at the time when you need them can pose a noticeable risk to the outcome of your project. It will pay dividend to figure out who you will need and what mitigation options you will have if you don’t get the people right when you need them and need to work around their schedules. Similar risks need to be identified with mitigation measures planned out accordingly during this phase.

After all these considerations are factored in, you should have sufficient information to put together a statement of work or an assessment project charter. The assessment charter will guide your effort and serve as the foundational governance piece as you move forward with the project. In the future posts, we will discuss kicking off the assessment, various approaches of collecting, validating, and analyzing the assessment data, plus presenting the finding and following up.

DIY Process Assessment Planning – Problem Definition, Scope, and Stakeholder Analysis

In the previous post, we talked about some potential information resources you can use to set up an internal ITSM process assessment effort. In this post, we will discuss some of the planning considerations that should be taken into account.

Problem Definition (Purpose and Opportunity)

It is always important to answer the question of “Why Bother?” In order for an assessment to produce meaningful results, it needs to address one or more business problems at hand. Document what are the drivers for conducting the assessment. Document why it is important to address the drivers now. Clearly identify what the organization or the sponsor intends to do with the assessment results. Once the purposes have been articulated with the agreement and support from the sponsor, the assessment team can use them as part of future communications to the stakeholders and participants.

Scope (Process and Organization)

The scope usually comes in two aspects, process scope and organization scope. An assessment can cover one or more ITSM processes, and the assessment purposes defined in the previous section should help to guide the scope definition.

The organization scope also needs to be defined for the assessment. Ideally an ITSM assessment should cover the entire IT organization but that may or may not be needed depending on the business problem you are trying to solve. Defining the organization boundary for the assessment can also be tricky partly because people and political considerations inevitably get involved. It is possible that the assessment will cover only a portion of the organization where the sponsor has more control over, infrastructure operations vs. application development as an example. When that happens, it is important to define clearly just how applicable the assessment’s scope is organizationally. That way, the assessment results will not be misinterpreted, and the follow-up action plans can be appropriately planned and executed.

For the process scope, the assessment should focus on assessing a process’ end-to-end effectiveness, or customer experience from the business perspective. It is quite possible that an overall assessment for a particular process will yield a score that may be different than what an individual team or organization expects. When that happens, it is important that the assessment can provide data to back up its finding or to explain the difference in expectation.

Also, don’t lose sight of the following. One reason to conduct assessment is to baseline what your organization is currently doing. Take advantage of the assessment opportunity to document the baseline performance of your processes, even for those which have had very little formal implementation or performance record.

Analysis of Stakeholders and Participants

Identifying and understanding the interactions stakeholders may have with the assessment is a critical aspect of the assessment planning. The stakeholders or participants of the assessment project can include a number of individuals such as the process owners, the IT staff, senior IT management team, key suppliers, and business customers. There are a number ways of mapping and understanding the stakeholders’ impact to the project. For most assessment projects, I would suggest thinking about the following factors. Customize the list further if your organization requires it.

The stakeholder’s view of the assessment effort: Some participants feel strongly about the assessment for whatever reasons, and some feel less so. Try to gain a better understanding of the participants’ views towards the assessment.
The stakeholder’s power to influence the assessment: Understand what role a participant will play in the assessment and how much influence they may have over the direction and execution of the project.
The stakeholder’s work or responsibility impacted by the assessment: The assessment will have variable degree of impact to the participants’ work or functional areas. Take this factor, along with the view and influence considerations, you can gauge what impact a stakeholder may have on your project more effectively.
The stakeholder’s need for communication or training: Understand and map out the communication strategy based on the information or reporting needs of the stakeholders. Some stakeholders will require periodic updates (say weekly) from the assessment team. Some participants may require more frequent or less frequent communication. Also understand whether the participants will require some form of awareness training or education prior to the actual start of the assessment activities.

At the next post, we will discuss the additional planning factors such as the assessment model, the schedule and deliverables, as well as the risks and constraints.