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:
-
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.
-
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.
-
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.
-
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.
-
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.
There are several project management methodologies and practices to choose from, and the best approach depends on the specific needs and goals of the project. Here are some of the most popular project management methodologies and practices:
- Agile: Agile is a flexible, iterative approach to project management that emphasizes collaboration, adaptability, and delivering value to the customer. Agile methodologies include Scrum, Kanban, and Lean.
- Waterfall: Waterfall is a linear, sequential approach to project management that involves completing each phase of the project before moving on to the next. It's a more traditional approach and is useful for projects where the requirements are well-defined and unlikely to change.
- Stable: The Stable Framework™ is an Operational Excellence model for project management and operations that can be combined with Agile, or can be performed stand-alone.
- RINCE2: PRINCE2 is a project management methodology that provides a structured approach to managing projects, including defined roles and responsibilities, a focus on the business case, and a step-by-step approach to project delivery.
- PMI's PMBOK: The Project Management Body of Knowledge (PMBOK) is a framework developed by the Project Management Institute (PMI) that provides guidelines for managing projects across a range of industries and project types.
- OPPM: The One Page Project Manager is a spreadsheet-based approach to Project Management.
- VI Sigma: Six Sigma is a data-driven methodology that focuses on improving processes and reducing defects in products and services. It's often used in manufacturing and other industries where quality control is critical.
In addition to these methodologies, there are several project management practices that can help ensure project success, including:
- Defining clear project objectives and deliverables
- Establishing effective communication channels and regular project status updates
- Assigning roles and responsibilities to team members
- Developing a comprehensive project plan and schedule
- Identifying and managing risks throughout the project
- Monitoring and controlling the project's progress against the plan
Ultimately, the best project management methodology and practices will depend on the specific needs and goals of your project. It's important to assess the unique requirements of the project and choose the approach that's best suited to meet those needs.
The term "Gherkin" is associated with Agile user stories because it is the name of a specific format for writing user stories that was introduced by the Cucumber testing framework. Cucumber is a popular open-source tool for Behavior-Driven Development (BDD), which is a software development methodology that emphasizes collaboration between developers, testers, and business stakeholders. The actual name is credited to Dan North, the creator of BDD, in a May 2006 blog post.
The Gherkin syntax is a way of writing user stories in a structured format that can be easily understood and shared by all team members, including non-technical stakeholders. The Gherkin syntax uses a simple language that is designed to be readable by both technical and non-technical people. It consists of a set of keywords, such as "Given", "When", and "Then", that describe the steps of a user story.
The Gherkin syntax is named after the small pickled cucumber, which is a reference to the idea of "pickling" or preserving the requirements of a user story in a structured, easy-to-understand format. The name was chosen to reflect the simplicity and ease of use of the syntax.
The Gherkin syntax has become popular in the Agile development community because it provides a standardized format for writing user stories that can be easily understood and shared by all team members. It can also be used to automate acceptance testing, as the steps of a user story can be mapped to test cases that verify that the software meets the requirements specified in the user story.
A Project Management Office (PMO) and an Enterprise Project Management Office (EPMO) are both centralized groups within an organization that provide project management guidance and support to ensure that projects align with the organization's goals and objectives. However, there are some key differences between these two types of offices.
A PMO typically focuses on managing projects within a specific business unit or department, while an EPMO has a broader scope and oversees all projects across the organization. An EPMO is responsible for developing and implementing a standardized approach to project management across the organization, including processes, tools, and templates.
The primary responsibilities of a PMO include providing project management guidance and support, monitoring project performance, and ensuring that projects are aligned with the goals and objectives of the business unit. The PMO also facilitates communication and collaboration between project teams, stakeholders, and senior management.
The responsibilities of an EPMO, on the other hand, are much broader. In addition to the responsibilities of a PMO, an EPMO is also responsible for developing and implementing a project management methodology that is used across the entire organization. The EPMO ensures that all projects are aligned with the organization's strategic goals and objectives and that projects are prioritized and resourced appropriately.
An EPMO also typically has more authority and influence within the organization than a PMO. It has a higher level of oversight and governance over projects and may be responsible for strategic planning and decision-making related to project portfolios. An EPMO may also be responsible for managing the organization's project management resources, including project managers and other project management professionals.
In summary, while a PMO and an EPMO share many similarities, an EPMO has a broader scope and is responsible for overseeing all projects across the organization, while a PMO typically focuses on managing projects within a specific business unit or department.
Establishing a Project Management Office (PMO, sometimes called EPMO for 'Enterprise' PMO) within an organization can be a complex and challenging process. Some of the common challenges that organizations face when creating a PMO include:
- Resistance to Change: One of the biggest challenges of establishing a PMO is resistance to change from employees and stakeholders. Some employees may not want to adopt new project management practices or may be skeptical about the need for a PMO.
Solution: To overcome resistance to change, organizations should clearly communicate the benefits of the PMO to all stakeholders and involve them in the process of creating the PMO. It is important to create a culture of change management that encourages all stakeholders to actively participate in the PMO creation process.
- Lack of Resources: Creating a PMO requires a significant investment in resources, including personnel, technology, and training. Organizations may struggle to allocate the necessary resources to establish a PMO.
Solution: Organizations should develop a clear business case for the PMO that demonstrates the value it will bring to the organization. They should also allocate sufficient resources to support the PMO, including personnel, technology, and training.
- Difficulty in Identifying and Prioritizing Projects: Organizations may struggle to identify and prioritize projects that align with their strategic objectives. Without clear guidance, it can be difficult for project managers to determine which projects to focus on and how to prioritize them.
Solution: Organizations should establish a clear process for identifying and prioritizing projects, and communicate this process to all stakeholders. The PMO should provide guidance and support to project managers in determining which projects to focus on and how to prioritize them.
- Lack of Project Management Maturity: If an organization lacks project management maturity, it can be challenging to establish a PMO that can effectively manage projects and deliver value to the organization.
Solution: Organizations should assess their project management maturity and identify areas where they need to improve. The PMO should provide training, coaching, and support to project managers to improve their project management practices.
- Resistance to PMO Governance: The PMO may face resistance from project managers who may feel that PMO governance is too rigid and inflexible, which can hinder project delivery.
Solution: The PMO should establish governance frameworks that are flexible and adaptable to the needs of individual projects. The PMO should also provide guidance and support to project managers in following the governance frameworks to ensure that projects are delivered on time, within budget, and to the required quality standards.
Establishing a PMO can bring many benefits to an organization, but it can also be challenging. Organizations must be prepared to address the challenges that they may face when creating a PMO. By implementing the solutions outlined above, organizations can overcome these challenges and establish a PMO that can effectively manage projects and deliver value to the organization.
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:
-
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.
-
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.
-
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.
-
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.
-
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