The ADKAR model is a popular change management framework that helps individuals and organizations understand the stages of change, and how to manage change effectively. The ADKAR model was developed by Jeff Hiatt, the founder of Prosci, a leading change management firm.

ADKAR is an acronym that stands for:

1. Awareness: This stage involves creating awareness about the need for change among the people who will be affected by it. This includes understanding the reasons for the change, the benefits of the change, and the potential impact of the change.

2. Desire: In this stage, individuals need to have a desire to support the change. This involves understanding why the change is necessary and how it will benefit them and the organization.

3. Knowledge: Once individuals have a desire to support the change, they need to acquire the knowledge necessary to make the change successfully. This includes training, education, and communication about the change.

4. Ability: In this stage, individuals must have the skills and ability to make the change happen. This may involve providing additional resources, tools, or support to help people adapt to the change.

5. Reinforcement: Finally, in this stage, individuals need to be reinforced and rewarded for making the change. This includes recognizing and celebrating successes, and providing ongoing support and encouragement to ensure that the change becomes a part of the organizational culture.

The ADKAR model is a useful framework for managing change because it focuses on the individual level, and helps to ensure that people have the necessary knowledge, skills, and motivation to make the change happen. By following the ADKAR model, organizations can increase their chances of success and achieve their desired outcomes.

PMI (the Project Management Institute) has recently introduced new content into it's curriculum....the Process Owner and Process Manager.  The distinction between these two roles seems to originate from ServiceNow's influence.

In small organizations the same person wears both hats, but in larger organizations these two roles may be split between two people.  Basically the Process Owner is a senior person responsible for "working on" the process, to improve it, while the Process Manager "works in" the process to execute it with efficiency.  A description of each role follows:

Job Description for Process Owner:

Process Owner's are responsible for the end-to-end oversight of a particular business process within an organization. Their main responsibilities include designing, implementing, monitoring, and continuously improving the process to ensure it meets the organization's goals and objectives. Process owners also ensure that the process is compliant with regulatory requirements and industry standards. They work closely with cross-functional teams to identify areas for improvement and implement changes that increase efficiency, reduce costs, and enhance quality. Other key responsibilities of a process owner include:

• Developing and maintaining process documentation, including standard operating procedures (SOPs), process flowcharts, and process metrics.
• Monitoring process performance using key performance indicators (KPIs) and other metrics, and identifying areas for improvement. (Note, both roles include this bullet point as it is an ongoing common point of review and discussion.)
• Leading process improvement initiatives, including process re-engineering and process automation.
• Collaborating with other process owners to ensure that processes are integrated and aligned across the organization.
• Communicating process changes to stakeholders, including senior management, process users, and customers.
• Providing training and support to process users to ensure that they understand and follow the process.

Job Description for Process Manager:

Process managers are responsible for the day-to-day management of a particular business process within an organization. They ensure that the process is executed efficiently and effectively, and that process users comply with the process requirements. Process managers work closely with process owners and cross-functional teams to identify areas for improvement and implement changes that increase efficiency, reduce costs, and enhance quality. Other key responsibilities of a process manager include:

• Ensuring that the process is executed in compliance with regulatory requirements and industry standards.
• Monitoring process performance using KPIs and other metrics, and identifying areas for improvement. (Note, both roles include this bullet point as it is an ongoing common point of review and discussion.)
• Providing training and support to process users to ensure that they understand and follow the process.
• Identifying and addressing process issues and bottlenecks that impact process performance.
• Collaborating with other process managers and process owners to ensure that processes are integrated and aligned across the organization.
• Communicating process changes to stakeholders, including senior management, process users, and customers.
• Developing and maintaining process documentation, including SOPs, process flowcharts, and process metrics.

Overall, while both roles are involved in managing and improving business processes, the process owner has a more strategic and high-level focus, while the process manager has a more operational and hands-on focus. The process owner is responsible for setting the direction of the process, while the process manager is responsible for executing the process according to the owner's direction. The process owner is more involved in initiating and leading process improvement initiatives, while the process manager is more involved in implementing and monitoring process changes on a day-to-day basis.

The Hidden Factory is everything your group does over again because it didn't go right the first time around.

This ranges from re-doing a failed multi-year project, to re-pushing a production release which had some minor issues the first time around. Sometimes these activities are called "Fire Fighting."

Most groups I talk to tell me that about 35% of their teams efforts are lost to this problem.

Someone must pay for this, and it's very expensive.  Higher prices, lower wages, and lower shareholder dividends are one way to quantify the hidden factory.  In addition, the opportunity cost of not being able to reach your project monetization goals 33% faster means you left money and customers on the table.

The Stable Framework™ is a performance management framework for IT designed to give IT departments the tools needed to tame this wild Hidden Factory beast and bring the fire-fighting down to nearly zero, where it should be.

Read more about it here

Mike Berry

The software development life-cycle (SDLC) is the process of planning, designing, building, testing, and deploying software. There are various models for the SDLC, each with their own advantages and disadvantages. Here are some of the most common models:

1. Waterfall model: The waterfall model is a linear, sequential approach to software development, where each stage is completed before the next one begins. The stages include requirements gathering, design, implementation, testing, and maintenance. This model works well for projects with well-defined and stable requirements, but can be inflexible and slow to respond to changing requirements.

2. Agile model: The agile model is an iterative and incremental approach to software development, where software is developed in short cycles called sprints. The stages include planning, requirements gathering, design, implementation, testing, and deployment, and the process is repeated in each sprint. This model works well for projects with evolving requirements and a need for flexibility, but can be challenging for teams that are new to agile methodologies.

3. Spiral model: The spiral model is a risk-driven approach to software development, where risks are identified and addressed in each stage of the SDLC. The stages include planning, risk analysis, design, implementation, testing, and deployment, and the process is repeated in a spiral fashion as risks are identified and addressed. This model works well for projects with high levels of complexity and uncertainty, but can be time-consuming and expensive.

4. V model: The V model is a variant of the waterfall model that emphasizes testing and verification throughout the SDLC. The stages include requirements gathering, design, implementation, testing, and maintenance, and the testing process runs in parallel with the development process. This model works well for projects with a strong emphasis on testing and verification, but can be inflexible and slow to respond to changing requirements.

5. DevOps model: The DevOps model is a collaborative approach to software development that emphasizes the integration of development and operations teams. The stages include planning, development, testing, deployment, and monitoring, and the process is highly automated to enable rapid and frequent releases. This model works well for projects with a need for rapid release cycles and a high degree of automation, but can be challenging for teams that are new to DevOps methodologies.

Each of these models has its own strengths and weaknesses, and the choice of model will depend on the specific requirements of the project, the experience and preferences of the team, and the organizational culture. Successful software development requires careful planning, effective communication, and a willingness to adapt to changing requirements and circumstances.

The Project Management Institute (PMI) announced a new certification for Business Analysts.  Called the Professional in Business Analysis, the PMI-PBA is a program for business analysis, and many other professionals who perform business analysis activities.

Think of Business Analysis as what happens before a project, the Scope development and change management happening during a project, and the post-release RIO work that may happen after a projects.  

Before a large project concept is approved, a Business Analyst may be commissioned to perform a feasibility study, and assuming the concept is feasible, create a Business Case Analysis showing the most recommend option and a few lesser options.

Assuming the Business Case is approved by the proper authority, a project is created and the Business Analyst transfers their information to the new Project Manager and may or may not become part of the team.

If they become part of the team, they likely will manage the Scope baseline, while the Project Manager manages Schedule and Cost baselines. During this process they will also work closely with the Project Manager to implement change control.  They will also makea good 2nd witness for assessing how well the project team is working with other stakeholders.

When the project is complete, they will help evaluate the projects success criteria, which was put into the Project Charter from the Business Case they created. If the success criteria is met, the project can be Closed.  

Any post-solution deployment ROI work can be measured and calculated by the Business Analyst to determine if the target ROI was reached with the solution. This target ROI, and the pre-determined techniques to measure it are found in the Benefits Measurement Plan, also created by the Business Analyst to compliment the original Business Case. Multiple measuring points and a Statistical Process Control chart, and an efficiency frontier chart can be used to assess ROI.

Mike Berry Red Rock Research

I attended an excellent presentation hosted by the Northern Utah PMI Chapter, featuring Mike Sandberg, Novell's Chief Business Analysts.  Mike spoke to a room of well over 200 folks about the CBAP certification.  This is the Certified Business Analysis Professional credential that us now coming of age.Mike talked about his own experience discovering the CBAP community and about the successes and issues involved with adopting the framework.

Specifically, Mike spoke about how the PMP and CBAP roles work together.  He talked about some challenges regarding turf and terminology that sometimes befall newer groups.

Someone in the audience asked Mike about how CBAP fits in with Agile.  Mike explained that this is a common question and that the business analyst would be most suited for the Agile Product Owner role. This se to make the most sense to me, and to the others present.

Mike J. Berry www.RedRockResearch.com