ITSM Misinformation and the (ITSM) Walking Dead

Recently the question again arose, in the Back2ITSM Facebook group, as to whether “zombie ITSM” is a thing. My emphatic response was, “Oh yeah, it’s a thing”. The viral effects of misinformation about IT service management (ITSM) that rot the brains of those that accept “guidance” from those with only enough “knowledge” to be dangerous. The shadowy things lurking within your ITSM design, eating resources, and consuming humans as they work harder not to follow practices than they would if they followed them. The bureaucratic, over-engineered, over-designed, constraint-laden adaptations that suck the life out of provider and customer alike. These represent just some of the scenarios facing all too many at work every day as they navigate their particular iteration of the zombie experience (ZX) thanks to the ITSM misinformation.

I want to offer to be your guide and walk through a few examples, and perhaps arm you with a few zombie-fighting implements to help you better survive if any of them remind you of your own day-to-day. Stay close…

ZX 1: The (ITSM Misinformation) Virus

All too often, the zombie effect on ITSM begins with misinformation that spreads like a virus, carried by those unknowingly affected by it, moving from person to person and embedding itself in your organization.

Have you ever been told that your business must do something because ITIL/Agile/DevOps, etc. “says so”? In the past ten years, have you been given ‘training’ that tells you ITIL still stands for “IT Infrastructure Library” or that you must adopt every process and practice it has? Or that if you are “doing Agile,” you don’t need change management (enablement)? Or that if you’re “doing DevOps,” you don’t need ITSM at all? If any of these symptoms (or many others) garner a ‘yes’, you have indeed been exposed (to this ITSM misinformation)… though most people don’t realize it.

This is what makes this form of the ZX so insidious; it tricks you into believing you’re doing the right thing, even when the outcomes of doing it are not those your business or customers need or desire. But how do you combat something that has been accepted as normal? By wielding what is so often the best weapon: evidence.

When the outcomes of your practices are not reaching the level your business requires, there are reasons, even if they’ve not been identified yet. If you’re “meeting your SLAs” but your customers are still not happy, or the business needs updates completed in three days, but your support teams tell you they can’t do it in less than ten, or people in your Teams chats are discussing certain activities they just cannot get done, you may be seeing the symptoms of “the virus.” Examine your numbers. Re-evaluate your measurements. Walk the workflows or activities your people are performing. You may find these symptoms are caused by something someone was told where they had to do it that way, but in reality it makes no sense to do it that way… or at all.

Then, research how this happened. Was the guidance from a verifiably legitimate source? If so, was it interpreted and adopted as it should have been for your organization? Should it have been adopted in the first place? Identifying these things can lead to a cure for ITSM misinformation, or at least a way to better manage the symptoms.

ZX 2: Lurking in the Shadows

Hidden behavior exists everywhere there are people; it’s an inevitable extension of group dynamics. Put people together, and there’ll always be some that engage in activities that are not aligned with the rules that have been established. I use the term ‘rules,’ but actually mean anything from informal moral expectations to formal regulations, laws, and practices. Put more simply, anytime you have rules, you eventually have rule breakers.

Shadow activities typically occur when an approved process or practice, that an organization expects to be followed, is in some way considered to be unworkable by some (or even all) of those expected to comply with it. The reasons people choose to ignore or bypass expected behavior and do something else are myriad; there’s no one answer to the question of “why?”.

Ever eat at your desk – even though the policy is not to? Take home office supplies? Cheat on a diet? Turn on the red traffic light even though the sign said not to, or any of countless similar actions? So, why did you do that? The answers to this question will be the same ones that explain why shadow activities happen. Understanding this is a key first step, since if you grasp this you should also understand the natural corollary: you really can’t prevent such behavior, you can only mitigate it – because you should never assume having a rule, process, practice, etc. in place to be enough to ensure compliance. That way lies disappointment – and zombies. And there is an additional challenge to this ZX: both zombies and those trying to survive are prominent players.

This is because there are two main causes behind the shadows: resistance to your ‘rules’ because there is truly a better way to do something, but “normal” business channels have prevented it from being approved (survivors), or resistance born of an intentional or unintentional misinterpretation of your ‘rules’ fostered by the perception that the hidden way is better (zombies). In either case, such activities can remain in place for years without being detected because, by their very nature, they’ll result in (at least the appearance of) the same outcomes as the ways of working that the business has approved.

The best way to begin uncovering shadow activities is to assume they’re there and actively look for them; they’re hidden, after all, so finding them may take a bit of unconventional investigation. For example, most organizations now have a number of internal social media mechanisms. Since we love to commiserate, there is a tendency many have to share things there that they otherwise wouldn’t, often doing that when discussing corporate policies and practices. Another thing to watch for will probably seem counterintuitive: watch your metrics for any areas that are statistically better than others following the same rules or process. Yes, better. Why? Because if everyone is following the same process yet some seem to be producing significantly (again, statistically) better results, chances are good that everyone is in fact not following the same process. The tendency when seeing such results is to simply say, “Why can’t the rest of you do this!” It’s another flavor of ITSM misinformation.

My advice is to take such results with a proper pinch of salt and find out just how they’re being achieved before accepting they’re as good as they appear.

ZX 3: The Omega Man Experience

Is your organization so entrenched in bureaucracy and mired in constraints that all anyone can do is just get through the day, shuffling between endless, fruitless meetings and performing activities that result in no value – and yet your coworkers accept this as ‘normal’? Do you spend your day killing off zombie activities only to find twice as many have taken their place? Welcome to the Omega Man experience, the all too common result of not addressing zombies when “the virus” first begins to take effect (back in ZX 1).

Some folks in this position may have witnessed (and even tried to prevent) this scenario; many find themselves playing the part because they’re made part of an “improvement effort.” Most will feel they’re the only one left that isn’t “zombified” – though typically they are not, even if they don’t know there are others like themselves.

Once more, there is no one factor to point to that explains how this happens to a business. However, there are a couple of common reasons. The first reaches into the dark past, all the way to the 1990s…

This is where the ITSM history most people are familiar with stems from: the early days of ITIL (don’t groan, you know it’s true). Regardless that many practices ITIL put to paper were invented and utilized well before ITIL came to be, it’s there that so many saw them “formalized” and learned of them. Unfortunately, that formalization contained a great deal of, albeit unintended, rigidity and bureaucracy (as well as ITSM misinformation) that you still see applied even today. Exacerbating this, next came training and consulting organizations that further cemented conceptions that were to become ingrained and extremely difficult to overcome, even those that changing ways of doing business should have left far behind. Add to this the explosion of social media and the ability for anyone with an internet connection to purport being an “expert,” even when they were nothing of the sort.

Any organization that did not recognize and overcome these causes likely ended up at some point getting drunk on processes and otherwise opening the gates to the zombie hoards. And, once so many have succumbed, it’s so much more difficult to recover from.

There is still hope though, if you can find some other survivors in your organization that can join you in forming a community that can begin to foment change (though if your organization is quite small you may be able to start on your own). Find small things that you can change for the better and show the powers that be it can be done. Don’t try to defeat all the zombies at once – you can’t and will only end up getting eaten. Coming back from the brink is a slow process, but it can be done if you’re brave enough.

Regardless of your zombie experience (through ITSM misinformation), you can survive, and even prevail, if you’re willing to take up the right approach and fight back. Just remember, you’re not alone…

Source: itsm.tools.com

Continue reading

Program Manager Vs Project Manager

In this blog post, we will explore the role of a project manager and a program manager and how they differ.

However, before discussing the roles of these two titles, let’s understand projects and programs.

According to the PMBOK Guide, a project is a temporary endeavor to create a unique product, service, or result. 

A program manages more than one similar project under a single umbrella for better management and more efficient resource utilization.

Projects and programs are key to organizational success, and they serve different objectives.

The difference between projects and programs are as follows:

1. Projects are temporary and have a defined beginning and end, while programs have a longer duration. 

2. Projects involve a team of people who work together to complete the project. On the other hand, programs have project managers and some supporting staff.

3. Projects require more resources than programs.

4. Projects are more complex than programs. 

5. Projects generally have a higher risk than programs. Programs are typically less risky than projects.

6. Projects are initiated in response to a specific problem or opportunity. Programs are initiated for strategic purposes.

Program Manager Vs Project Manager

Now we will discuss the difference between the program manager and the project manager.

Program Manager

A program manager coordinates multiple similar projects and oversees various aspects of a program. 

In many cases, they are responsible for developing the program plan, coordinating resources, and ensuring that the program meets its objectives.

Program managers require a diverse skill set because of the wide range of responsibilities required. They must possess strong communication, problem-solving, organizational skills, and the ability to manage people and resources. Program managers have to deal with multiple tasks among different projects simultaneously.

Project Manager

A project manager is responsible for managing projects. This includes developing a project management plan, executing the project, monitoring and controlling, and closing it.

Project managers usually have a background in engineering or business administration. 

Project managers must possess strong leadership skills to motivate team members to meet deadlines. They must handle conflicts and make decisions in the project’s best interest. They should communicate with project team members and management effectively.

Project management is a challenging but rewarding career. It can be a fulfilling profession if an individual possesses the necessary skills.

Roles and Responsibilities

The roles of a program manager include:

◉ Defining the program and its objectives.

◉ Developing a plan to achieve those objectives.

◉ Managing the resources among the project under the program.

◉ Ensuring that the program meets its targets.

◉ Coordinating the activities of all participants in the program.

◉ Reporting on progress and ensuring that lessons learned are captured.

The roles of a project manager include:

◉ Developing a project plan.

◉ Hiring team members.

◉ Assigning tasks to team members.

◉ Creating schedules.

◉ Monitoring the progress of the project.

◉ Make changes to the project plan as needed.

◉ Ensuring that the project is completed on time and within budget.

◉ Reporting to the program manager.

Differences Between Program Managers and Project Managers

◉ Program managers are responsible for managing a program consisting of multiple similar projects. In contrast, project managers are responsible for managing individual projects.

◉ Program managers have a more strategic focus, while project managers have a more tactical focus. Put simply, program managers have a big picture focus, while project managers focus on the details.

◉ Program managers are responsible for developing the program plan and coordinating resources among projects. Project managers are responsible for planning, executing, and monitoring the project.

◉ Program managers manage projects and resources among projects Project managers manage projects and influence factors causing changes.

◉ Program managers are often in managerial roles, while project managers are in technical roles and work under program managers. 

◉ Program managers have more authority than project managers.

◉ Program managers work with projects for a longer timeline, while project managers typically work with shorter ones.

Examples of Job Positions

Project Manager Positions

Examples of project management positions and their responsibilities are given below.

Project Manager for Software Development

Project managers for software and web development coordinate and manage software and web development projects. 

Here are some of their responsibilities:

1. Defining software characteristics with developers and clients

2. Budgeting and allocating funds for software development initiatives

3. Handling software testing, troubleshooting, and evaluation throughout the development phase

Technical Project Managers

These project managers are in charge of overseeing the implementation of IT or technology projects.

Their responsibilities include the following:

1. Come up with solutions to technical challenges and assess hazards

2. Managing the purchase of project materials and negotiating rates with suppliers

3. Leveraging their technical skills to create project plans that are aligned with the company’s objectives

Program Manager Positions

Examples of program management positions and their responsibilities are given below.

Manager of Human Resources

A human resource (HR) program manager’s responsibilities include:

1. Creating job classification specifications

2. HR training program design

3. Analyzing HR trends to create and adjust program objectives

4. Creating and modifying human resources policies and procedures

IT Program Manager

An information technology (IT) program manager’s job entails collaborating across departments to resolve IT difficulties.

The following are some of their responsibilities:

1. Providing guidance on IT management policies and practices

2. Examining IT operations to evaluate the needs of the information system

3. Advising top management on strategies for integrating applications within the organization

Skills

The skills required for a program or project management career are almost similar. Below are the key skills needed for the role of program manager and project manager.

Program Manager

1. Strategic Thinking: A program manager sees the big picture and understands how the various parts of the program fit together. They need to think ahead and develop plans to achieve the desired results.

2. Strong Communication Skills: A program manager needs to communicate effectively with all stakeholders, including executives, project managers, and top management. They need to be able to articulate complex ideas clearly and concisely.

3. Organizational Skills: A program manager manages multiple projects and tasks. They need to have excellent time management skills and stay controlled under pressure.

4. Resource Management: A program manager needs to manage resources and time effectively.

5. Analytical Skills: A program manager needs to analyze data and make informed decisions. They need to understand the implications of their decisions and how they will impact the program.

Project Manager

1. Technical Expertise: A project manager must understand the technical aspects of the project. They need to troubleshoot problems and make decisions to keep the project on track.

2. Leadership: The project manager needs to motivate and inspire team members to perform well. They need to build consensus and make tough decisions.

3. Change Management: A project manager must influence the factors causing changes in the project.

4. Communication Skills: A project manager needs to communicate effectively with all stakeholders, including executives, management, and suppliers. They should keep everyone up-to-date on the latest developments.

5. Project Management Skills: A project manager must understand project management principles. They must be able to plan, execute, and monitor projects.

Program Manager and Project Manager Certifications

There are a few different certifications that program and project managers can pursue, depending on their interests and goals.

Program Manager

◉ Program Management Professional (PgMP)

◉ Certified ScrumMaster (CSM)

Project Manager

◉ Project Management Professional (PMP)

◉ Certified ScrumMaster (CSM)

◉ Lean Six Sigma Green Belt (LSSGB)

The details of the above certifications are as follows:

1. CAPM: Certified Associate in Project Management (CAPM) is for individuals who want to work in project management as an entry-level position. The certification is issued by the Project Management Institute (PMI), USA.

2. PMP: The Project Management Professional (PMP) is the most widely held project management qualification worldwide. The Project Management Institute is in charge of administering the PMP.

3. PgMP: The Program Management Professional (PgMP) certification is intended for program management professionals. This advanced certification demonstrates mastery of the skills needed for a successful career in program management. The PMI issues this certification.

4. Scrum Master Certificates: The most common scrum master certifications are Certified ScrumMaster (CSM) and Professional Scrum Master (PSM I).

5. Lean Six Sigma Green Belt (LSSGB): The LSSGB is a certification for project managers who want to apply Lean and Six Sigma techniques to their projects.

6. Google Project Management Professional Certificate: This six-month (or shorter) certificate program accessible on Coursera helps individuals prepare for entry-level project management roles.

Source: pmstudycircle.com

Continue reading

Does APICS CPIM Certification Help Build Your Manufacturing Career Skills?

Many professionals believe that companies value the APICS CPIM certification because it delivers a third-party guarantee that their knowledge and skills extend past on-the-job experience and college education. As a result, thousands of supply chain and processes professionals across the country are enrolling in courses to follow APICS certification.

APICS CPIM is determined internationally as the standard of professional capability. Boost valuable production and inventory administration expertise, improve internal operations, and increase complete consumer satisfaction.

About APICS CPIM Certification

The APICS CPIM is acknowledged globally as the standard of professional competence. Increase functional knowledge of production and inventory, enhance internal operations and improve customer satisfaction.

The APICS is a professional certification supplied by APICS since 1973, recognized globally as a standard in production and inventory. So far, more than 1,00,000 professionals have achieved this designation to showcase their dedication to the profession. This certification improves the professional value of the individual, enhances the earning potential, and provides a career advantage over peers.

One can learn essential terminologies, concepts, and strategies related to different knowledge areas like procurement and supplier planning, demand management, MRP, capacity needs planning, sales and operations planning, master scheduling, performance measurements, supplier relationships, etc.

Career Opportunity of APICS CPIM

APICS CPIM has completed its research and found that people with CPIM designations have gotten about 14% greater compensation than those without the classification.

Why You Ought to Earn the APICS CPIM?

• Grow your salary - generally, designees see a 21% growth.
• APICS Certified individuals report wages 18% more than those with other certifications.
• Career advancement.
• Professional growth.
• Increased reliability and also an acknowledgment.
• Shown commitment to advancing your occupation as well as your firm’s operations.

By earning the APICS CPIM, you are a recognized specialist in operations and a valuable asset for your company. Dedicate on your own to a greater level of knowledge and skill, increase your job leads, and assist any organization to remain affordable in today’s economy.

The APICS CPIM candidate will undoubtedly learn how to enhance manufacturing and decrease expenses by tactically looking outside internal procedures and throughout the supply chain.

APICS CPIMs work across a wide range of professions consisting of:

• Production
• Consulting
• Education
• Government
• Services
• Defense
• Health care
• Distribution

The APICS CPIM program supplies you with the capability to understand and review production and inventory tasks within a firm’s international operations.

Provides a complete testimonial of qualification subjects, including crucial terminology, principles, and strategies related to demand management, master organizing, quality control, and continual improvement.

Shows tested methods for improving performances and improving your firm’s profits. The technique is an instructor-led proficiency evaluation that will explain these subjects' concepts, key concepts, best practices, terminology, and application while leading individuals to the additional research study required to pass the CPIM Test.

Significance of APICS CPIM Certification in 2022

APICS CPIM certification supplies a regular basis for people to examine their expertise in the advancing field of materials management. CPIM qualification has been recognized worldwide as a standard of specialist skills in Supply Chain Management (SCM). The apparent dedication to expert development as well as advancement.

The CPIM program consists of five modules. For each module, there is an exam that will test your learning. APICS offers different study options to get you through the program at different paces. You can choose to study with classroom review methods or instructor-supported online courses with a set rate. You can also decide to self-study and set your own pace.

If you self-study, it is likely to work hard and acquire the certification in as little as three months. It will be easier to satisfy the program quickly if you have background knowledge in supply chain management or a related field. If you require more time, APICS states that you can take three years to pass two exams to get your certification.

Learning Outcome:

• Increase your salary-on average, and designees see a 25% increase.
• Improve your hiring potential by 65%.
• Career advancement.
• Professional growth.
• Increased credibility and recognition.
• Demonstrated commitment to advancing your career and your company’s operations.
• Certified Production and Inventory Management course are recommended for:
• Buyers and Planners
• Materials Manager
• Production Managers
• Consultants

Conclusion

APICS CPIM design, you will have the skills and expertise it takes to get found by companies and to draw attention from your peers. Making the APICS CPIM qualification will show your commitment to progressing your occupation and your firm’s operations.

Many professionals believe that companies value the APICS certification because it delivers third-party assurance that their knowledge and skills extend past on-the-job experience and college education. As a result, thousands of supply chain and processes professionals across the country are enrolling in paths to pursue APICS certification.

Continue reading

Architectural Data will Guide the 2020s

What technical and financial analytics should CIOs and decision makers expect from Enterprise Architects in 2022?

Enterprises are in the middle of an application explosion and a transformation acceleration.

Looking just at the application landscape: industry surveys tell us that the average enterprise is using 1,295 cloud services, and also runs around 500 custom applications. The worldwide enterprise applications market reached $241 billion last year, growing 4.1% year-over-year in 2020, according to IDC. 

The underpinning architectures of enterprises– made up of interactions between people, processes and technology, and often also physical assets (IoT) – are also growing and changing at pace.  

Enterprise Architects keep CIOs and business units informed using IT cost calculations and technical and lifecycle metrics.

They will often present costs and technical metrics for the current IT landscape, plus forecasts to inform planning for new business scenarios and digital transformation projects.

Common analysis in past years might have covered:

◉ Counts of applications

◉ Total cost of ownership of applications (also ROI and NPV)

◉ Which processes rely on a particular software or infrastructure (dependency analysis)

◉ How long technology is going to be supported, and when the enterprise needs to transition or upgrade

This basic data is useful but might still leave decision makers wanting additional analysis or tighter granularity.

Business units want to understand how much updated processes or applications will lead to improved technical metrics (uptime, responsiveness) or improvements to processes which are important for successful customer journeys.

Enterprise Architecture Data Analysis in 2022

Data-driven enterprise architecture can now provide greater detail and certainty around forecasts. Architects and business users need to design calculation which roll up data numerically across the architecture, generating required KPIs on-demand.

For the data scientists and numerate business analysts, steps such as Add, Subtract, Multiply, Divide, Min, Max, Average and Count are standard. In addition, operations such as Power, Log and Atan can be used to calculate trends, probabilities, attribute values and measure or predict impacts of business decisions.

As well as diagrams and roadmaps, EAs often need to be ready to provide reporting dashboards which include:

Technology Cost Analysis:

◉ On-demand totals of how much out-of-date technologies are costing the business

◉ Total cost of a specific Business Capability or Process – using the connections and relationships in the architecture to attribute portions of costs accurately

◉ More precise cost-of-ownership (e.g., calculating software, support or external services costs according to business function) Costs of underlying infrastructure or resources used. EAs can calculate the total cost of ownership of out-of-date technologies (available as a pre-built cost simulation in tools such as ABACUS from Avolution)

◉ Cloud migration costs

◉ Technical debt metrics such as remediation cost, complexity, cost of compliance

Lifecycles & Trends in Metrics

◉ Cost of risks and vulnerabilities associated to applications and technologies

◉ Technology and vendor lifecycle information summaries e.g., Number of years to retirement of a technology

◉ Application portfolio assessments: calculate and chart business fit and technical fit of applications and technologies. E.g., Are our applications using approved technologies, and are these technologies currently being supported by the vendor? (The base data for this analysis can be pulled in from sources such as Technopedia)

◉ Technical KPIs including Response Time, Availability, Reliability, Resource Utilizations

◉ Trends in metrics such as rate of growth in costs, or rate of increase in Availability or Reliability

◉ Machine-learning based predictions: E.g., Use lists of applications, lifecycles, financial data and other architectural content. For instance, the machine learning engine in ABACUS from Avolution provides a quantitative prediction of the values which belong in any empty cells. An ‘empty cell’ for an application, machine learning will propose a TIME (Tolerate-Invest-Migrate-Eliminate) recommendation, which the architects can choose to accept, for a more complete dataset.

Adding KPIs to Diagram-based Enterprise Architecture

◉ Comparison of future vs current state. Architects can dashboard side-by-side comparisons of information or technical architecture designs plus related catalogs and use these and  related metrics to monitor transformation projects

◉ Risks associated with specific processes (security ratings and risk ratings can be rolled up from technologies and applications to the processes they support)

◉ Comparing tasks by mapping tasks or processes to capabilities. For instance, as part of a consolidation during a merger or acquisition, architects can calculate costs or technical KPIs on processes to determine efficiency of the two versions of the process.

◉ Dependency analysis of a process: using diagrams and Graph Views to see connections e.g. to highlight where a process is dependent on outdated technology.

◉ Show systems, interfaces and APIs as part of process diagrams

Analysis by Architects on data from APIs

Architects can also present data pulled in from CMBDs or other company data sources (via API queries) as stakeholder dashboards. Charts and interactive visuals are often clearer and easier to explain than lists of data.

◉ Architects can use tools such as Postman to run queries on APIs

◉ Common API integrations include Technopedia a range of CMDBs, and VMware products

We’re in the foothills of a golden age of architectural analysis. Businesses understand their external environment and run their sales functions with data from business intelligence tools and modern sales platforms. They are applying the same quantitative approach to their internal enterprises, a joined-up universe of data on people, processes and technologies.

Source: opengroup.org

Continue reading

SIAM and SLAs

How far should your organization take service level agreements in a service integration and management world, i.e. what’s the need for SLAs in SIAM? SIAM is when an organization adopts a multi-vendor sourcing approach to IT services. This approach requires the creation of a new service management function – a SIAM function – with this having the ability to span a multi-vendor environment and integrate the services provided by these vendor “towers” into a set of end-to-end service outcomes.

With more organizations seeking to take a SIAM approach, an organization’s service architecture model must be well understood. In other words, the services provided by the third-party service providers, the SIAM function, and internal service providers work well together to form a coherent whole. And, importantly, that all understand this need.

Creating a service architecture model

A service architecture model is required to achieve this. This model not only shows the topology but also describes, at a high level, the services provided by each of the vendor towers. From this organizational starting point comes the question of SLAs (plus operational level agreements (OLAs) and underpinning contracts (UCs) if your organization is still using ITIL v3/2011 terminology).

This area is fraught with pitfalls, in my experience, and there’s a risk of seriously over-complicating what’s required. This situation is typically due to various conflicting requirements from different camps:

◉ Legal teams – When a SIAM function is created because of multi-vendor sourcing activity, the various legal teams of the parties involved will work together as part of the deal. However, their low appetite for risk (and some would say, high appetite for fees) will place a heavy emphasis on OLAs and contracts not only between the SIAM function and their respective vendor tower but also between the towers.

◉ The SIAM function – The SIAM function, as custodians of the services, will want – and maybe need – to create SLAs with the business. This “want” is highly commendable, but to develop these it could be argued that they first need to obtain a statement of service capability and performance from each service provider, be they internal or external, in the supply chain.

◉ Service providers – The service providers, both internal and external, will want to avoid being involved in a lesser-known ITIL process – “blame management.” The service providers will want to ensure that their dependencies on others in the service model are called out. This is usually achieved via a contract or OLA. It’s typically defined within the “ops-book” or “service manual,” which accompanies the contract as a practical set of day-to-day operational guidance.

◉ The customer – This is perhaps the most important stakeholder in the service model. But sadly, one that’s often overlooked. I should have placed them at the top of this bulleted list, not the bottom! The customer might be skeptical of the perceived restructuring and reorganization (in IT) that comes with the revised sourcing arrangements. Consequently, they’ll want or need reassurance that the new service will be reliable and available, plus able to deliver the business operations and outcomes it enables.

Bring this around to SLAs in SIAM: The customer will want their SLAs tied down, and tied down very tightly. So, where do SLAs too often go wrong?

Common SLAs in SIAM issues

First, the SIAM function will likely listen to everyone’s requirements and then try to accommodate them all. However, without a service model in place to verify them, there’s no “sense-check.”

Second, in their keenness to make a good impression, the service providers decide to start engaging directly with the end customer. This engagement undermines and bypasses the role of the SIAM function when the service provider exposes too much of the service’s “inner-workings” to the customer. This approach usually opens up lines of communication and escalation that the SIAM function would prefer to be firmly closed!

Third, the service model is drafted “on-the-fly” – where multiple workstreams for developing SLAs, OLAs, underpinning contracts, and other documentation are initiated in parallel.

And what happens to all this SLA documentation?

It’ll likely sit on a shelf, gathering dust even if it gets finished. It might also be missing a supporting governance model that ensures all understand the report requirements, meetings, and rules of engagement. However, commonly the “SLAs in SIAM project” never gets finished because it’s just too complex.

It’s why we recommend that organizations developing or sourcing a SIAM function need to first define their service model end-to-end. This model describes the relationship between the many parties and the services provided by each. This model can then be used as the basis for prioritizing the most important documents and their contents – the ones that will add the most value to the SIAM ecosystem. Those that don’t will be created in a later phase.

The best piece of advice I can give anyone on SIAM service models is “keep it simple.” If you can’t describe your service model to the customer, or even your parents, then you’ve overcomplicated it! This complexity will then adversely affect your SLAs.

Source: itsm.tools.com

Continue reading

It is okay to fail! (And other lessons your project team must learn)

To be successful, it is paramount that project professionals know what failure looks and feels like. Only through our failures can we learn important lessons for the future, and discover how to truly appreciate success. And so, as leaders, we must teach our project staff the important truth that it is okay to fail. Here’s some other lessons for your project teams:

Plans are changeable

Planning is central to project management. The PRINCE2 methodology places high value on the processes of starting up and initiating a project. When we are clear on what we want to achieve in a project, we use that vision to drive us, and strategy soon follows. However, project professionals must also understand that there is rarely a clear path to achieving the vision, particularly in the case of complex projects. And that’s where Agile practices come in.

Agile allows plans to be flexible and changeable. PRINCE2 Agile training is the ideal way to teach your teams this ‘best of both worlds’ lesson. The course equips them with the tools and knowledge needed in order to adapt and change through the course of the project, and is supported by the processes of the PRINCE2 methodology.

Resources can be fluid

When it comes to agility, a further valuable lesson is that resources can be fluid. Whether it’s in terms of capital, materials or assets, establishing that these are not fixed and immovable is an important project lesson. By treating resources as flexible, project teams are able to get the most out of the tools, budget, equipment and people that form a project. Flexible resource management will improve efficiencies and contribute to the project’s success.

For flexible use of resources to be triumphant, it is essential that project teams track utilisation, as this provides an understanding of whether your resources are working at maximum efficiency. Plus, in the case of shifting staff onto other tasks, employees should be cross-trained – a skill-sharing practice we looked at in a previous blog post. This allows them to jump in, switching roles for the benefit of the project.

The freedom to experiment

Cross-training employees goes hand-in-hand with building a culture of continuous improvement. Creating an environment where project teams can experiment as part of continual improvement can be beneficial, both to the project and to the individual’s competencies. As leaders, we must empower project staff with the freedom to experiment, set hypotheses, and gain insights from the results.

So long as the team has a shared vision, and devises measurable experiments as part of the mission for progress, experimenting can be advantageous on the project journey. It can have a great impact on the outcomes of a project, and should be encouraged. Innovation works together with agility as a way to react and respond to external factors, helping us adapt and adjust to take our next steps in the project accordingly.

How to handle failure

When all is said and done, ‘learning to fail’ really depends on how you define failure. In project terms, a failure is often framed as a project which comes in late or over budget. However, that is not to say that it was not a success. Its execution may well have been flawless despite this, and the project may have met goals and achieved the desired results.

On the project journey, what really matters is how teams handle failures. Project professionals must be free to make mistakes, and to learn from those mistakes. They must not be constrained by them, but use them as valuable insights that inspire improved future actions, levelling up their skills and practices. Only by crafting this open and accepting culture will you gain a team with the mindset to succeed going forward.

Source: prince2.com

Continue reading

Difference between Project Management and Service Management

1. Project Management :

Project management, as name suggest, is simply management that ensures that all projects within organization are executed in most effective manner and are delivered on time.

2. Service Management :

Service management, as name suggests, is simply management that is customer-focused and helps in increasing and maximizing business value by use of IT i.e. information technology.

Difference between Project Management and Service Management :

Project Management	Service Management
It mainly focuses on management of individual project.	It mainly focuses on management and delivery of IT services so that customer can be benefited form it.
It is a temporary management process that works till project is completed.	It is a permanent management process i.e. an ongoing Lifecyle process.
Project manager have more responsibilities than service manager.	Service manager have less responsibilities than project manager.
Factors affecting project management includes suppliers, risks, communication channels, procurement issues, team building issues, timing issues, etc.	Factors affecting service management includes inadequate staff, poor planning and designing, lack of communication among others, etc.
Process of this management includes initiation, planning, execution or performing, monitoring or checking and closing particular project.	Process of this management includes designing, creating, delivering, supporting and managing overall lifecycle of IT Services.
Its benefits include improve chances of achieving main desired goal, set scope, improves growth and development within team, etc.	Its benefits includes provide value, improve efficiency, reduce operational cost, improve effectiveness, improve visibility, etc.
Its main objective is to complete temporary projects simply to deliver and achieve desired goal of organization or business or company.	Its main objective is to ensure that correct processes, technology and members are put in place so that organization or business or company can be able to achieve their desired goal.
Project management is more difficult than service management.	Service management is less difficult than project management.

Source: geeksforgeeks.org

Continue reading

Five reasons why PRINCE2 is a fantastic qualification to have

PRINCE2 – a qualification fit for royalty.

Devised in the 1990s, this project management qualification has been helping people across the country ensure their projects keep on time and budget. Since it was created, over a million people have become PRINCE2 certified.

If you haven’t studied PRINCE2, you may be wondering if it’s the right accreditation for you, especially with other project management qualifications readily available. However, we think it’s the perfect certification, no matter which industry you work in.

Join us as we look at what PRINCE2 is, and how it can help you manage projects like a pro.

What is PRINCE2?

PRojects IN Controlled Environments, or PRINCE2, is a project management method that helps people in business manage their projects more effectively.

PRINCE2 was developed in 1996 in the UK. It was initially created to help IT project managers in the government sector. However, it became so popular that use quickly spread across government and was also adapted for use in the private sector too. It’s currently used across a wide range of different businesses and industries.

Many businesses love using PRINCE2 as unlike other project management methods; there are no licensing fees to pay.

PRINCE2 focuses on breaking a project into stages so you can determine who is responsible for each stage and identify any potential risks as early as possible. If you’ve ever created a Gantt chart, these play a significant part in the PRINCE2 planning process!

Ultimately, PRINCE2 will lead to projects being completed on or before the deadline and with added cost-efficiencies. It’s a win-win for both you and your business!

The seven principles, themes and processes of PRINCE2

The key methodology of PRINCE2 is seven principles, themes and processes that can be used to map and monitor projects from beginning to end.

Why PRINCE2 is a fantastic addition to your CV

As you can see, PRINCE2 is a brilliant way of managing any projects you have, breaking them down into smaller, more manageable chunks.

Here are some reasons why PRINCE2 should be your project management qualification of choice.

1. It’s recognised all across the world

If you ask most recruiters to name a project management qualification, they’re likely to say PRINCE2!

Not only is a PRINCE2 qualification immediately recognisable on a CV, but it’s recognisable worldwide too. This qualification is practised in over 50 countries, meaning that PRINCE2 will make a welcome addition to your job application no matter where you are.

2.  It’s transferable across a wide range of industries

PRINCE2 has been designed to be industry-agnostic. This means that no matter the type or size of your business, you can use the PRINCE2 method to generate fantastic results.

This can have its benefits as you move up the career ladder and gain more experience. If you earned your PRINCE2 qualification while you were working in manufacturing, and then made a move into IT, you can still apply what you learned to your new role.

You can use PRINCE2 in other ways too – some of our students have used it to plan their holidays or children’s birthday parties!

3. It’s fully customisable

The problem with many project management methodologies is that there is a framework that you have to strictly follow. This can lead to inflexibility, as well as to frustration.

The great thing about PRINCE2 is that it can be integrated into any other project management techniques you use, making it easy to adapt to your own way of working.

Let’s take the Gantt charts we mentioned earlier as an example. They can be a major help when managing your project. However, if you’re not comfortable using them and would prefer to use another method, like a PERT chart or critical path analysis, you can.

If you’re a fan of Agile project management, you can combine this with PRINCE2 too!

4. It’s tried and tested

The PRINCE2 qualification has been around for nearly thirty years, and bar a couple of revisions, uses the same methodology as it always has.

This means PRINCE2 is a solid and reliable accreditation that will lead to tangible results, and businesses around the world acknowledge this.

5. It can lead to an increase in salary

A PRINCE2 qualification can open the door to a brand new role, as well as an increase in pay.

Whether you opt for the Foundation or Practitioner qualification, PRINCE2 shows that you can see a project to completion, efficiently and cost-effectively.

A Product Support Officer can expect a salary of £29,500. However, a Programme Manager can anticipate an average salary of £75,000!

Source: itonlinelearning.com

Continue reading

Difference between Project Management and Channel Management

1. Project Management :

Project management, as name suggest, is simply management that involves processes, methods, skills, understanding, and experience to achieve desired objective of project and meet project requirements.

2. Channel Management :

Channel management, as name suggests, is simply management that focuses on handling various streams that are employed by company simply to sell their goods or services or products.

Difference between Project Management and Channel Management :

Project Management	Channel Management
It mainly focuses on management and organizing project work individually along with its resources.	It mainly focuses on management and developing programs or techniques for selling and servicing customers.
It is a temporary management process and has defined beginning and end in time.	It is a permanent management process.
Project manager have more responsibilities than channel manager.	Channel manager have less responsibilities than project manager.
Project management includes various activities such as scope management, scheduling management, identifying stakeholders, defining objectives of project, etc.	Channel management include various activities such as process synchronization, process communication, deadlock handling, suspension of processes, resumption of processes, etc.
Types of project management includes PRINCE2 project management, scrum management, agile management, Lean management, etc.	Types of channel management includes reverse channels, direct selling, selling through intermediate, dual distribution.
Process of this management includes initiating, planning, execution, monitoring and closing project after its completion successfully.	Process of this management includes analyzing customer, establish channel objective, specify distribution tasks, evaluate and select among channel, evaluate channel member performance.
Its benefits include service delivery effectiveness, competitive advantage, improve flexibility, increased quantity, etc.	Its benefits includes increase customer satisfaction, streamline communication, develop program for selling, etc.
Its main objective is to complete project successfully and provide guidance to project team’s operation so that goal can be achieved.	Its main objective is develop and establish direct communication with customers in each and every channel.
Project management is more difficult than channel management.	Channel management is less difficult than project management.

Source: geeksforgeeks.org

Continue reading

Better project planning in 5 simple steps

Planning is one of the most valuable stages in the PRINCE2 methodology. Initiating a project carries a lot of responsibilities. Planning can be both challenging and time-consuming as it comprises numerous activities. It involves preparing and refining your approach for everything from risk to communications, quality methods to change controls, and much more.

Yet all too often, planning can be rushed through, overlooked, and under-valued in the project journey. With some minor tweaks to processes, planning can be optimised to be more efficient, easier, and more effective throughout the project lifecycle. Here’s how you can ensure your project plan succeeds effortlessly:

1. Build in a contingency plan

When met with roadblocks at the planning stage, project professionals can feel under-equipped to resolve them. Restraints in budget, time, resources or knowledge can result in plans being executed with known errors in place. Taking the time to be risk averse can allow project staff to build contingencies into their plans. It may be that extra resources may be needed, that you need to have substitutions in place in terms of employees or contractors, or even an alternate source of capital. A safety net of contingencies can help to ensure smooth sailing further down the line. It could even be make or break for a project.

2. Allow for adaptations

Likewise, a contingency plan does not have to be set in stone. It’s less a matter of having a ‘plan A’ and a ‘plan B’, and more about knowing that if problems occur, you are equipped to handle them. PRINCE2 Agile training echoes this. It combines the flexibility of Agile with the framework of PRINCE2 and teaches that practices can be tailored in order to be responsive.

The pandemic has taught us to be adaptable, and combined with PRINCE2 Agile, this knowledge and experience can be used to our advantage when planning, and throughout the project. The PRINCE2 Agile framework values continuous monitoring – with Agile ways of working, such as sprint reviews and retrospectives.

3. Get visual!

By actually seeing your project mapped out, it is far easier to visualise it being a success. If you’re not sure where to start, consider using a Project Initiation Document (PID) which can be used as a checklist so that you, and your team, can visually confirm that plans have been well considered. With this as the basis, you can build upon your plans and modify them; expanding them to include risks, contingencies, project controls and more in depth project plans. This may be something you can do within your regular project tools. Or you may work through plans in a Kanban style in software such as Trello, or even mock them up in a whiteboard session! Visually seeing project plans can be of huge benefit for both leaders and project teams.

4. Improve your communication practices

If it’s been a while since you reviewed your practices and made internal changes in areas such as communication, when planning a project, it is an ideal time to do so! Or perhaps you have made changes, but it has been transformational and gone undocumented? Either way, for a project plan to work effortlessly, it is vital that you get all staff on the same page, and a written-up communication plan is fundamental for this.

Define how you are going to communicate throughout a project, the types and channels you will use, and the frequency of communications to unite teams. Bringing teams together is of particular value when you have remote and hybrid workforces. Consistent, open communication will manage employees’ expectations, and work to improve project productivity and outcomes too.

5. Value accountability

Processes for staying accountable are undervalued and usually overlooked in project planning. Yet simple daily accountability practices can be revolutionary, and it all comes back to your communication approaches. For one, implementing routines such as daily standups, a highly valued tool in Agile Scrum, is a great way to keep tabs on progress and flag any looming issues before they cause delays.

Another technique is implementing accountability ‘buddies’. Partner up employees so that they check in with each other. Much like daily scrums, partners will have a quick discussion on what they achieved the day before, what’s on the agenda for today, and any challenges they may face. This is a great way to improve motivation, productivity, accuracy and efficiency.

Source: prince2.com

Continue reading