Tag: Process

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.

Golf and Tennis

Both golf and tennis are competitive sports. Many people play the games, but there are only so many highly-skilled players.

Both sports involve hitting a small object with an apparatus, but it takes two different approaches to succeed in them.

Playing great golf takes a well-executed process. When the process of swinging is executed consistently with very little or no error, the golf ball will always travel to the spot where the golfer wants it to be. Of course, assuming the same environment conditions such as winds, ground texture, etc.

Playing great tennis takes a well-executed practice. Practice is where the knowledge, skills, and judgment of the player come together in response to the current situation on hand.

Playing golf takes consistency and predictability, so each swing will always get the ball to where it needs to go.

Playing tennis takes flexibility and unpredictability, so each time the ball will go to where your opponent least expects it to be.

Playing golf with the unpredictable swings will likely result in a poor score.

Playing tennis with a predictable consistency will likely get you pwned by your opponent.

Many organizations spend a great amount of effort to perfect their processes. At the same time, they need to spend just as much time to develop a practice that can deal with change and unpredictability thrown at them.

People, Process, Technology

“People, Process, and Technology” (or PPT) is a popular formula used in many process frameworks, ITIL included.

This model has worked well for the corporate factory age. In today’s increasingly idea and connection-oriented economy, an updated model is needed.

In “The Cognitive Enterprise” by Lewis and Lee, Customers, Communities, Capabilities, I believe, are the new PPT.

Customers do not appear in the PPT formula, but customers ultimately define value.

Communities promote the connection between people, internal and external. Communities and connections enable the free flow of ideas.

Capabilities are more than a combination of processes and technologies. Capabilities further enable the Customers and Communities to achieve results.

The “Three C’s” are the new PPT for our connection economy.

Book Review: An Integrated Requirements Process by Peter Brooks

Summary: Compelling recommendations for instituting an integrated requirement management process in any enterprise

After managing IT projects and practicing IT service management for a number of years, the idea of having an integrated requirement process (IRP) for an enterprise intrigues me. I am certified in ITIL and have studied IIBA’s BABOK and ISACA’ COBIT frameworks. I was particularly interested in reading Peter’s recommendations for managing enterprise requirements.

The author proposed IRP based on the premises that:

Requirements are corporate assets and should be methodically captured, tracked, managed, and re-used for the benefit of the enterprise.
Many frameworks describe the needs of capturing and managing requirements but do not go into more details on how requirements should be properly captured and managed
An unified view of the requirement is necessary and can be leveraged by other IT frameworks and activities

Why would you want to read this book and examine the proposed process? I think the book is relevant if you are looking for:

A starting point into a more organized and formalized requirement management process for your organization
Ways to capture requirements from discrete projects into a centralized enterprise repository and to leverage their re-use
Recommendations for integrating requirement management more seamlessly with other IT activities/lifecycles such as application development, business analysis (BABOK), ITSM (ITIL), and IT governance/audit (COBIT).

How would this book help you? After reading the book, I think you will be able to:

Define or design a requirement management process for your organization. For example process flow, roles and responsibilities, recommended CSFs and KPIs
Define or design categories and statuses to enable a requirement managing workflow for logging, tracking, and re-use of the requirements
Define or design the necessary measurements for evaluating the IRP’s effectiveness
Understand or identify the necessary controls for governing and sustaining IRP
Understand or identify the integration points between IRP, BABOK, ITIL, and COBIT
Understand or identify supporting tool requirements

In summary, Peter has provided some compelling reasons and recommendations for instituting an integrated requirement management process in any enterprise. The book has defined all the necessary elements for designing, implementing, and governing the IRP. Peter also has taken a great deal of care by adding plenty of worked examples to help explain the process. I believe his recommendations provide an excellent starting point for those who are ready to manage requirements as corporate assets, rather than just one-time project occurrences.

Change Management Process Design – Part 2

This post is part two of a series where we discuss the ITIL-based Change Management process and how to put one together. In the previous post, I presented some design considerations such as goal/purpose; the intended scope; and roles and responsibilities. In this follow-up post, I will discuss additional process governance and planning elements.

Categorization and Prioritization

Why do we categorize? Proper categorization can facilitate or drive certain governance decisions. Categorization can drive the lead time required for review and approval. Categorization can also determine what process workflow or approval authorities may be required to facilitate the change. ITIL recommends three types of change request: Standard, Emergency, and Normal. If ITIL’s definitions work for your organization, go ahead and adopt them. However, that categorization alone is probably not sufficient to describe the changes and how they affect the business operation. Finding a way to describe the risk and impact associated with a change is also important. Risk can be used to measure the level of the potential disruption of business operation associated with a change request. Impact can be used to measure how far-reaching a change can be. The key idea here is to find a way of properly assessing changes and managing risks.

When designing a categorization scheme for changes, I recommend examining your existing incident and problem categorization scheme and make an attempt to have a consistent categorization across the ITSM processes. I believe that a uniform categorization will make risk assessment more reliable than not having it. A consistent categorization could also make the design and analysis of the reports more meaningful. Some organizations choose to use separate categorization schemes for incidents, problems, and changes – a decision sometimes influenced by the organizational boundaries or the tools on-hand. Just keep in mind that a change management exercise is also a very much a risk management exercise.

Workflow and Documentation

Once you have the change requests categorized, you will need a workflow to process the change requests for review and approval with a well-defined lead time. These lead-times are necessary to provide the adequate time required to review and to approve the change request by the change manager and the stakeholders. Many organizations I was with have had either weekly or semi-weekly CAB review cycles. That means the approval and scheduling timing need to be well defined so CAB and change manager can review, discuss, approve, or even escalate the change with sufficient time. Also, different types of change or change risks/impacts will likely require different lead-times or maybe different work-flows to process them. Some organizations may be required to impose change freeze windows in order to support critical business systems or processes.

Just like other ITSM artifacts, change requests should be documented and, ideally, captured in a tool. The levels of detail needed to be capture will vary from one organization to another, but most organizations should capture the baseline of required data such as:

Change requester, owner, and implementer
Type, category, risk, impact, priority as defined in the process document
Configuration items (systems, applications, devices, etc.) affected by the change
Summarized and detailed description of the change
Business justification
Proposed schedule or implementation timing
Dependencies and required resources identified
Key approvers needed
Final report on the closure of the change

Once the changes are captured and processed, the process guide also needs to define the necessary communication and coordination mechanisms to support the change management activities.

Metrics and Measurements

Tracking and measurement are the key elements to the continual process improvement. Depending on the goal and purpose defined for the change management process, we can further define the critical success factors and the key performance indicators we will need to track in order to measure the effectiveness, efficiency, and the quality of the process. The process design should spell out the metrics requirements and make sure the tools can support the required metrics.

Process Integration

It will also be useful to define some potential connecting ITSM processes to CHM. Incidents, problem, change, configuration, and release management process all have activities that are closely tied to one another. Which processes will trigger the CHM process from an upstream workflow or will receive the CHM output downstream? If you have an incident identified and it requires changes implemented to restore the service, how will those changes be handled? If you practice problem management in your environment, how will CHM process be injected into the root-cause remediation or deficiency remediation activities? Will the incident tickets, problem records, configuration items, and requests for change be linked in some fashion? These are just some governance related questions that should be considered upfront as they will affect how you plan and design the CHM process.

In the last two posts, we just went over a number of governance and planning elements for the change management process. We talked about the scope and purpose of the process, how we categorize and prioritize changes, the essential roles for executing the process, the necessary categorization, workflow, metrics, and integration with other ITSM processes. On the next post, we will go over and example process flow and spell out more details for the change management activities.