4 Types of Management Support Needed by Your Solution After the Project
The purpose of this post is to cover the four types of management needed to support your solution, so it continues to be current and deliver value.
Management Support is an aspect of managing Resources in the TRANSITION and CLOSE step, of the Project Management MPM model.
Management Support is an aspect of managing Resources in the TRANSITION and CLOSE step, of the Project Management MPM model
Four Types of Management Support
There are four main types of management support needed for your solution after the project is complete:
- Incident Management
- Problem management
- Change management
- Asset management
Four Types of Management Support
Each is covered in their own section below.
Depending on the complexity of your solution these hats may be worn by four different people and even four different management teams. Or, if your solution is simpler, or in a smaller company, one person may handle all four responsibilities.
Management support is covered under TRANSITION Resource Allocation. TRANSITION activities are covered in this blog post.
1. Incident Management
Incident Management is break-fix. The purpose of this role is to handle problems when they occur.
This includes taking the call from your end customer, logging the call, adding it to a list, and directing that to be handled, or fixed by someone.
This could be handed off to an individual or a team or it could be entered into a support tracking tool. There are many options for this, covering everything from a manual solution which tracks it on a list updated one at a time, to a sophisticated support tool with notifications and reporting.
Incident management can be handed off to an individual or team
One of the key pieces of information that needs to be obtained at this time, which is often not done, is determining root-cause. The root-cause is often not the problem first identified by the “customer” who called, sent the email, entered the chat, or submitted a ticket.
The root-cause is the actual problem, not what the customer observed or what the customer thought was wrong.
For example, the customer may have observed that they couldn’t get to the site where your new solution was. However, the root cause may have been they were using an out-of-date, unsupported browser that was not in-scope for your team to test. So, the root cause is “unsupported browser.”
The importance of capturing root-cause is that it provides the best quality input into the next management support area which is problem management.
2. Problem management
Problem management is analyzing the incidents that have happened over a period of time and determining which ones have the greatest occurrence and then fixing those occurrences or deciding on a form of action to take so they don’t continue to occur.
Other forms of action include education, awareness, or messaging.
Problem management examines incidents over a period
Problem management looks at the incidents over a particular period, sorting them from greatest to least frequency of root-cause.
Problems are normally resolved in order from greatest occurrence to least occurrence.
You don’t want to get good at fixing the same old problems, you want to get them resolved and reduced so there are less incidents and less problems.
When a set of problems is resolved and a new version is ready to be provided to your customer, the solution needs to be provided to the customer in a predictable, consumable manner and that is the job of change management.
3. Change (and Configuration) management
Change management in the support sense (because change management is used in a number of different contexts for a project) is controlling how the fixes are provided to the customer. This can also be referred to as configuration management, but here both are referred to as just change management.
Change management in support is about controlling the consistency, performance and functionality of the project’s solution over the life of the product. Change management is the control over what changes are done to the supported product.
If there is a break-fix incident that is urgent because there is no work around to the problem and it is preventing the customer from using the system, then the change is implemented as soon as a fix is available.
If the fixes are not urgent and can be packaged together to be released as a set, then the person or team doing the change management schedules it as a release, which is a group of changes or fixes, that are to be provided to the customer on a particular date and time.
Changes can require validation with pilot customer groups prior to their implementation to a broader group of users.
A group of changes to how the product operates, if it is not an urgent fix, is packaged as a “release”, meaning the release of a change to the user environment.
Change Management for support is planning releases
Change management releases can be monthly, quarterly or on an as-needed-basis, although most customers and support teams appreciate a planned set of fix releases, such as monthly or quarterly.
How change releases were performed, what incidents were resolved, and how the set of problems is increasing or decreasing, is covered in an annual review of the asset.
4. Asset management
Asset management is an annual review of how well the product, which is an asset, is performing for the end users.
This includes reviewing incident resolution, the progress in cleaning up the backlog of problems, how change releases have gone, and any other activities related to the project solution when it is in support.
Asset management looks at the solution as an asset, determines how it is meeting the needs of the customer and if any additional resources, such as more money, has to applied to make larger changes or improvements to the solution.
Asset management is really time to ask if the solution needs upgrading or improvement, to be continued as is, or if it needs retiring, replacement or removal.
Asset management does not have to be annual but can be at whatever time period is appropriate to determine the value of the solution as an asset to the organization and the user community and the best approach to managing that asset.
Summary
There are four main types of management support needed for your solution after the project is complete: Incident, Problem, Change (Configuration), and Asset Management.
Depending on the complexity of your solution these hats may be worn by four different people, four different management teams, or all by one person.
Action Steps / Apply This Knowledge
- For a project you have in progress, create a new document, add in the headings for the four types of management support and add a couple of sentences under each for how you envision it being supported.
- If from 1. above you uncover some gaps with teams or individuals that are necessary to play a support role for you project outcomes, then schedule those conversations now.
- Add these sections to your TRANSITION activities if that part of your project is coming up soon.
- Prompt engineering guidance for AI GPTs such as chatGPT: “I’m a business leader managing a project that has a core team of around X people involved, handing the solution off to a team of Y support staff, and the end solution will be used by about Z employees, and the project is now in the Transition and Close phase. What are some things I need consider, in light of the numbers just provided, when thinking about transitioning from a project to operations support?”
Learn More to Do More
Business evolves through change initiatives otherwise known as projects. The key to managing these change initiatives so you have more time, and less stress is to use simple strategies and tools.
Check out the Learning Hub’s other Articles with Actionable Steps, organized with a busy leader in mind, by topic or main idea, and with some AI GPT (e.g. ChatGPT) prompt engineering suggestions under the Action steps: https://simplepmstrategies.com/learning-hub-index
TRANSITION- Resource Allocation Management Support
© Simple PM Strategies 2024