A

Cadence describes the flow or rhythm of events or tasks in a project. It establishes a pattern that the team can follow to understand what they are doing and when it will be completed. Cadence also could be sending a project status meeting to all stakeholders every Friday without fail. Basically a task done at regular intervals no matter what. 

Agile teams strive to achieve a cadence during their project. For example, in Scrum, fixed-length iterations, called sprints, typically last two weeks and allow the team to ship software on a regular cadence. In Kanban, the cadence is the continuous flow of work.

Benefits:

• Establishes order and rhythm.

• Improves team efficiency.

• Allows the team to deliver software on a frequent basis.

Capability Maturity Model (CMM)

Developed from a US Department of Defense study, the model is used to develop and refine software processes. It helps to model the maturity of the capability of a business process by defining steps and managing result metrics to optimize the process.

CMM's Five Maturity Levels of Software Processes

• At the Initial Level, processes are disorganized, even chaotic. Success is likely to depend on individual efforts, and is not considered to be repeatable, because processes would not be sufficiently defined and documented to allow them to be replicated.

• At the Repeatable Level, basic project management techniques are established, and successes could be repeated, because the requisite processes would have been made established, defined, and documented.

• At the Defined Level, an organization has developed its own standard software process through greater attention to documentation, standardization, and integration.

• At the Managed Level, an organization monitors and controls its own processes through data collection and analysis.

• At the Optimizing Level, processes are constantly being improved through monitoring feedback from current processes and introducing innovative processes to better serve the organization's particular needs.

The CMM is similar to ISO 9001, one of the ISO 9000 series of standards specified by the International Organization for Standardization (ISO). The ISO 9000 standards specify an effective quality system for manufacturing and service industries; ISO 9001 deals specifically with software development and maintenance. The main difference between the two systems lies in their respective purposes: ISO 9001 specifies a minimal acceptable quality level for software processes, while the CMM establishes a framework for continuous process improvement and is more explicit than the ISO standard in defining the means to be employed to that end.

Capacity

Capacity represents the amount of work that can be completed within a certain time frame and is based on the number of hours that an individual or team will be available to complete the work.
The product owner and Agile team determine the capacity or amount of workload, they can take on for an upcoming sprint. The capacity is decided during the sprint planning meeting. Benefits include Improves resource management and Estimates the completion of a project.

Case study

Used for a variety of purposes, case studies are generally research-based papers that deeply examine use cases of products in given applications or how different industries applied specific practices or approaches to their projects.  A case study is an empirical method. It is a well defined, scientific, method for posing research questions, collecting data, analyzing the data, and presenting the results. Case studies are an in-depth investigation of one particular individual, group, time-period or event. They encompass a range of qualitative and quantitative research tools to investigate underlying principles of an occurrence within a real-life context.

Benefits:

Comprehensive

• The most significant benefit of case studies is that they enable a holistic review. Unlike standalone research techniques which give more of a snapshot, e.g. surveys, a case study offers the opportunity for a researcher to use a range of tools on one subject. This gives time and space to build a detailed understanding of the topic, establishing a sound platform from which to explore the factors influencing the case study in greater detail.

Reducing Bias

• Case studies capture a range of perspectives, as opposed to the single view of an individual you get with a survey response or interview. This gives the opportunity to gain a greater understanding of the subject in hand and reduces the potential for any bias, by diluting the agenda of a particular individual. 

Change control

The term for a process to systematically monitor and approve or reject any change requests made to a product or project. The process is designed to increase project efficiency and minimize scope creep by controlling every change and ensuring that changes are made according to set requirements for approving change. 

Whenever any new or different changes are requested for the system, especially by stakeholders, it is neither optional nor ignorable. It has to be implemented without affecting other components of the system. This is when the change control comes handy. It helps project teams to modify the scope of the project using specified controls and policies. Change Control is practiced whenever a project is not progressing as planned.

It is mandatory that a formal document for change request is completed and reviewed in order to keep control of change requests.

Number of question one might encounter while analyzing Change Control like

• Who will approve the change?

• Does it require to run through a change control board?

• How much time will be required to research and implement the change?

• What are the impacts of changes to other components of the system (schedules, cost, resources, etc.)?

• Is there any threshold under which the project management can approve it?

Change Process follows a specific pattern to implement the changes in the product or system.

Change request identification → Change request assessment → Change request analysis → Change request approval → Change request implementation

Steps of Change Control

• Change request identification

  • Identify the need for a change and describe it on the project change request form

• Change request assessment

  • If the change is not valid, it has to be deferred or rejected

  • Determine appropriate resources required to analyze the change request

  • Perform quick assessment of the potential impact and update the change request form

  • At this stage, rejected change request should stopped

• Change request analysis

  • For analysis assign the change request to an authorized member

  • Deferred change re-enter this analysis step

  • At this stage, rejected change request should stopped

• Change request approval

  • Identify change risk and complexity level before approval

  • Identify the impact level of the change before approval

  • Review impact of Change Request to authorized person for approval

  • At this stage, rejected change request should stopped

• Change request implementation

  • Update project procedure and management plans

  • Inform about the changes to the team

  • Monitor progress of change request

  • Record the completion of change request

  • Close change request

Process of Change Control

​

While carrying out Change Control, there are mainly two documents involved

Change Log: A change log is a document that lists the details about all the Change Requests like project number, PCR (project change request) ID, priority, Owner details, Target date, status and status date, raised by, date when raised etc. A change log should be maintained that tells the date, person details who made changes and changes implemented. Only authorized individuals should be able to make changes.

A process for rolling back to the previous version should be identified

Change Request Form: It is used to document details required to support the decision making process like type of change, benefits of change, name of resource requesting the change, time and estimate cost, priority of change, authorized person detail, change request status etc.

Chickens and Pigs

The terms “Chicken” and “Pig” come from “The Chicken and Pig Story” by Ken Schwaber, a software developer who helped formulate the initial version of Scrum. Most often used in Scrum, a “Chicken” refers to someone who is involved in the project, but is not accountable for any specific deliverable (such as a stakeholder or manager). On the other hand, a “Pig” is someone who is committed and directly accountable for deliverables. 

“The Chicken and Pig Story” by Ken Schwaber

A pig and a chicken are walking down a road. The chicken looks at the pig and says, “Hey, why don’t we open a restaurant?” The pig looks back at the chicken and says, “Good idea, what do you want to call it?” The chicken thinks about it and says, “Why don’t we call it ‘Ham and Eggs?’” “I don’t think so,” says the pig, “I’d be committed, but you’d only be involved.”

The pig and the chicken story delineates the kinds of people who attend the daily scrum meetings. The pigs are those who are on the chopping block - the committed people who have stakes in the project and are essential to its success or failure. The chickens are those who attend the meeting but have no direct relevance to the update, meeting progress or project. Thus, the chickens are the people who have something to say but usually have nothing to contribute. Considered the meeting eavesdroppers, chickens usually comprise 50 to 80 percent of the attendees at any given meeting.

How it’s Used: Chickens and Pigs are used to define participants and roles in Scrum. “Pig” roles are usually the actual team members, the Scrum Master, or the Project Owner. “Chicken” roles are managers or stakeholders. 

Benefits:

• Clarifies and defines roles.

• Sets projects expectations.

• Promotes accountabilities.

Collaboration

Working with one or more parties on the same project and similar goals. It’s the act of delegating and communicating between team members and distinct teams in order to better serve the product by providing more minds and hands. More than that, though, collaboration is a way of working with new tools like social platforms, real-time document sharing and editing, and remote working. For some companies, collaboration is perceived to be a “culture” promoted within the business to support Agile or iterative ways of running projects or simply to support knowledge sharing within the org.

Communications log

A record of continuous documentation of communications between project stakeholders managed by the project manager. Project managers make logs to manage change requests or to document public sector projects for future audit or oversight committees in more formal project environments. In more informal organizations, communications logs can be chats, discussions and email threads, and in fact some project management software adds email conversations related to the project directly on the task or project level, to keep project documentation organized.

Contingency

A plan for possible disaster occurring during your project, whether that be of the man-made or natural variety. It’s not merely data backup, but includes that and every other detail to ensure the project isn’t derailed by considering short- and long-term events and how to respond to them.

Continuous Improvement or Kaizen

Continuous improvement is a process of improving quality and efficiency by making small, incremental changes over time. In Kanban, continuous improvement refers specifically to the process of optimizing workflow and reducing cycle time, resulting in increased productivity. 

Continuous improvement is used to introduce improvement into the work process on an incremental basis and involves the following steps: 1) Identify, 2) Plan, 3) Execute, and 4) Review.

More specifically for Kanban, there are no set due dates so the team focuses on work-in-progress. As team members collaborate to troubleshoot problems and brainstorm new ideas, the process becomes more efficient and streamlined, cycle times decrease, and workflow is optimized. Teams do not need to be cross-functional in Kanban.

Project Management Benefits:

• Improves productivity and delivery.

• Increases accuracy in forecasting future work and delivery.

• Streamlines work and reduces waste.

• Introduces improvement on an incremental basis.

• Increases a sense of pride and accomplishment in team members.

Continuous Integration (CI/CD)

Continuous integration is a software engineering practice that involves continual integration of new development code into the existing codebase. 

CI/CD is a method to frequently deliver apps to customers by introducing automation into the stages of app development. The main concepts attributed to CI/CD are continuous integration, continuous delivery, and continuous deployment. CI/CD is a solution to the problems integrating new code can cause for development and operations teams (AKA "integration hell").

Specifically, CI/CD introduces ongoing automation and continuous monitoring throughout the lifecycle of apps, from integration and testing phases to delivery and deployment. Taken together, these connected practices are often referred to as a "CI/CD pipeline" and are supported by development and operations teams working together in an agile way with either a DevOps or Site reliability engineering (SRE) approach.

CONTINUOUS INTEGRATION ( BUILD → TEST → MERGE ) → CONTINUOUS DELIVERY (AUTOMATIC RELEASE TO REPO) → CONTINUOUS DEPLOYMENT (AUTOMATIC DEPLOY TO PRODUCTION)

Benefits: 

• Enables rapid feedback, so that defects can be identified and corrected quickly.

• Minimizes time and effort needed to perform each integration.

• Provides an automated build and release process.

• Allows software to be deliverable at any moment.

Contract

A contract is a mutually binding agreement which obligates the seller to provide the specified product and obligates the buyer to pay for it. Contracts generally fall into one of three broad categories:

• Fixed price or lump sum contracts—this category of contract involves a fixed total price for a well-defined product. Fixed price contracts may also include incentives for meeting or exceeding selected project objectives such as schedule targets.

• Cost reimbursable contracts—this category of contract involves payment (reimbursement) to the contractor for its actual costs. Costs are usually classified as direct costs (costs incurred directly by the project, such as wages for members of the project team) and indirect costs (costs allocated to the project by the performing organization as a cost of doing business, such as salaries for corporate executives). Indirect costs are usually calculated as a percentage of direct costs. Cost reimbursable contracts often include incentives for meeting or exceeding selected project objectives such as schedule targets or total cost.

• Unit price contracts—the contractor is paid a preset amount per unit of service (e.g., $70 per hour for professional services or $1.08 per cubic yard of earth removed) and the total value of the contract is a function of the quantities needed to complete the work.

Cost Overrun

This is the actual cost that exceeds the estimated cost in the budget, also known as a cost increase or budget overrun. It usually is unexpected and unwanted as it requires finding new resources to cover these unseen expenses. Cost overrun can be described in multiple ways.

• As a percentage of the total expenditure

• As a total percentage including and above the original budget

• As a percentage of the cost overruns to original budget

Cross Functional Team

Team comprised of members with all functional skills and specialties necessary to complete a project from start to finish. Cross functional collaboration is a group of people with different functional expertise coming together to work toward a common goal. In many cases, the team is simply a group of people from the different departments across a business working on solving a specific problem.

Collaboration is a natural part of working in teams, and in most organizations, it happens organically within functions or business units. However, it is less likely to occur across different roles, departments or functions - which are precisely the areas in which it has the potential for the maximum impact. Cross functional collaboration is critical to improving business performance.

Here are just a few of its advantages:

• Different perspectives spur innovation

  • Everyone sees problems from their own perspective, and the view can be very different from the marketing office than the production floor. Bringing people from different parts of the company together can shed light on process problems and deliver innovative solutions that satisfy everyone.

• Increased momentum of change

  • Involving people with different areas of influence from the beginning helps secure buy in, empathy, and trust.  There’s less “turf” to be protected and everyone is on the same page, so there are far fewer delays.

• Everyone Learns More

  • Collaboration with people who are experts in different areas of the business cross pollinates knowledge and helps everyone to understand how their work fits into the bigger picture. There’s certainly an advantage, for example, in having a marketing coordinator who understands how finance processes payments to vendors.

• Old Ideas are Challenged

  • Everyone knows how difficult it is to proofread your own work. A new set of eyes can be a huge help in finding errors and opportunities for improvement in all types of work. Cross functional collaboration creates an environment where “the way we’ve always done it” can be questioned and considered from a fresh perspective. 

• The Playing Field is Leveled

  • Structure and hierarchy are important elements of any organization, but sometimes a more multi- directional approach can yield greater results. Cross functional collaboration means that not all ideas come from the executive suite or a single department with a dominant leader. People at any level can participate in innovation and contribute to the execution of great ideas, which increases buy in and engagement on the front lines. 

Why is Cross Functional Collaboration So Hard?

• Lack of Trust / Build Trust

  • Tribalism or silo-building

  • Solution: Leaders can help bridge the silos and develop a culture of trust by aligning the goals and incentives of the organization as a whole, instead of rewarding selfishness and suboptimization. If mistrust is a barrier to collaboration in your organization, try starting with a few small opportunities for teams to work together to get quick wins. Seeing results can help develop trust. 

  • Successful collaborative efforts should be celebrated, and leaders should be sure to broadcast improvements widely. Leaders and team members should be held at least as accountable for their cross functional, big picture efforts as they are for their primary role.

• Social Loafing

  • Reduction in Effort. Lack of individual accountability causes social loafing. 

  • No common method for measuring impact. 

  • Solution: The cure for social loafing in cross functional collaboration is to develop a standard set of criteria by which each individual is measured. Continuous improvement software helps by giving leaders visibility into who is participating and who isn’t, so that recognition can be awarded to the high-performers, and the loafers can get more support and encouragement.

• Poor Communication

  • Too much or too little communication.  Balls can be dropped, deadlines missed. Too many meetings or an avalanche of emails can hurt productivity.

  • Communication is often a major issue with cross functional collaboration because departments operate as silos, with little back and forth between them. In fact, teams can develop their own language with words and phrases that have meaning only to them. Effective collaboration requires communication, so organizations that don’t actively support it struggle to act as a cohesive team.

  • Solution: The first step is to establish a common language around the entire organization’s improvement efforts. Adopting a business management methodology like Six Sigma or Lean can help because these approaches come with a shared vocabulary, but the same can be achieved without them.

  • 
    

• Misaligned Goals and Objectives / Alignment

  • Can lead to suboptimizing, where everyone prioritizes activities that will help them meet their own local goals, leaving little room for projects or improvements that will benefit other teams or the organization as a whole.

  • Solution: Organizations that are serious about continuous improvement and cross functional collaboration must make room in the reward structure for collaborative activities. This may mean rewarding success on cross functional projects separately, or allowing for time and energy devoted to such efforts within the framework of the departmental goals. Employees should have a clear understanding of how their collaborative work will be recognized, and know that such efforts won’t get in the way of their achievement of local objectives.

• Divergent Technologies

  • Pretty common for departments to each have their own technology that drives everyday work.

  • Solution: Companies that embrace continuous improvement should do so using technology designed specifically for that purpose. Continuous improvement software should be standardized across the company and easily accessible by every employee. This unified approach to continuous improvement has the advantage of supporting today’s improvement efforts and creating an improvement knowledge repository for the organization's tribal knowledge, an asset that will pay dividends long into the future.

Critical Path

The critical path consists of the longest sequence of activities from project start to finish that must be completed to ensure the project is finished by a certain time. The activities on the critical path must be very closely managed. If jobs on the critical path slip, take immediate action to get the project back on schedule. Otherwise, the whole project can be delayed. In a project network diagram, the series of activities which determines the earliest completion of the project. The critical path will generally change from time to time as activities are completed ahead of or behind schedule. Although normally calculated for the entire project, the critical path can also be determined for a milestone or subproject. The critical path is usually defined as those activities with float less than or equal to a specified value, often zero. See critical path method.

Imagine that you have a project that will take 30 days to complete. If the first activity on the critical path is 1 day late, the project will take 31 days to complete, unless another activity on the critical path can be completed 1 day earlier. The critical path essentially determines the end date in your project schedule

Understanding the critical path method involves determining which activities are critical to complete on time. But other activities that lie outside of the critical path may also be very important and require additional attention.

Critical path method (CPM)

An algorithm for scheduling a set of project activities, typically the “critical path” or shortest path through a project. It was developed in the late 1950s within the DuPont organization and Remington Rand company as a method to know mission-critical tasks. Modern project management software applications can streamline finding your project’s critical path to help you manage scope and monitor the project. 

A network analysis technique used to predict project duration by analyzing which sequence of activities (which path) has the least amount of scheduling flexibility (the least amount of float). Early dates are calculated by means of a forward pass using a specified start date. Late dates are calculated by means of a backward pass starting from a specified completion date (usually the forward pass’s calculation project early finish date).

• Early Finish Date (EF) – In the critical path method, the earliest possible point in time on which the uncompleted portions of an activity (or the project) can finish based on the network logic and any schedule constraints. Early finish dates can change as the project progresses and changes are made to the project plan.

• Early Start Date (ES) – In the critical path method, the earliest possible point in time on which the uncompleted portions of an activity (or the project) can start, based on the network logic and any schedule constraints. Early start dates can change as the project progresses and changes are made to the project plan.

Cycle

A cycle refers to the total amount of time it takes for a single task or work item to travel through the workflow from the beginning of work until it ships. 

Kanban methodology uses cycle time as its key metric, rather than velocity, as with Scrum. As Kanban teams become more efficient in optimizing workflow and producing deliverables, cycle times decrease and productivity increases. Cycles have no set time limits; rather, workflow is based on continuous delivery. Kanban teams with shared skills experience smaller cycle times. Teams should strive for both shorter and more consistent cycle times. Cycle times can also be applied in Scrum.

Benefits:

• Leads to continuous improvement.

• Increases ability to forecast future deliveries (with consistent cycle times).

• Increases productivity (with shorter cycle times).