Project Management Articles

Article / Updated 01-23-2024

Agile principles are designed specifically to increase the success of your projects. Agility in project management encompasses three key areas: Making sure the development team can be productive and can sustainably increase productivity over long periods of time Ensuring that information about the project’s progress is available to stakeholders without interrupting the flow of development activities by asking the development team for updates Handling requests for new features as they occur and integrating them into the product development cycle An agile approach focuses on planning and executing the work to produce the best product that can be released. The approach is supported by communicating openly, avoiding distractions and wasteful activities, and ensuring that the progress of the project is clear to everyone. All 12 principles support project management, but principles 2, 8, and 10 stand out: (2) Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. (8) Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. (10) Simplicity — the art of maximizing the amount of work not done — is essential. Following are some advantages of adopting agile project management: Agile project teams achieve faster time-to-market, and consequentially cost savings. They start development earlier than in traditional approaches because agile approaches minimize the exhaustive upfront planning and documentation that is conventionally part of the early stages of a waterfall project. Agile development teams are self-organizing and self-managing. The managerial effort normally put into telling developers how to do their work can be applied to removing impediments and organizational distractions that slow down the development team. Agile development teams determine how much work they can accomplish in an iteration and commit to achieving those goals. Ownership is fundamentally different because the development team is establishing the commitment, not complying with an externally developed commitment. An agile approach asks, “What is the minimum we can do to achieve the goal?” instead of focusing on including all the features and extra refinements that could possibly be needed. An agile approach usually means streamlining: barely sufficient documentation, removal of unnecessary meetings, avoidance of inefficient communication (such as email), and less coding (just enough to make it work). Creating complicated documents that aren’t useful for product development is a waste of effort. It’s okay to document a decision, but you don’t need multiple pages on the history and nuances of how the decision was made. Keep the documentation barely sufficient, and you will have more time to focus on supporting the development team. By encapsulating development into short sprints that last one to four weeks or less, you can adhere to the goals of the current iteration while accommodating change in subsequent iterations. The length of each sprint remains the same throughout the project to provide a predictable rhythm of development for the team long-term. Planning, elaborating on requirements, developing, testing, and demonstrating functionality occur within an iteration, lowering the risk of heading in the wrong direction for extended periods of time or developing something that the customer doesn’t want. Agile practices encourage a steady pace of development that is productive and healthy. For example, in the popular agile development set of practices called extreme programming (XP), the maximum workweek is 40 hours, and the preferred workweek is 35 hours. Agile projects are sustainable and more productive, especially long term. Traditional approaches routinely feature a death march, in which the project team puts in extremely long hours for days and even weeks at the end of a project to meet a previously unidentified and unrealistic deadline. As the death march goes on, productivity tends to drop dramatically. More defects are introduced, and because defects need to be corrected in a way that doesn’t break a different piece of functionality, correcting defects is the most expensive work that can be performed. Defects are often the result of overloading a system — specifically demanding an unsustainable pace of work. Priorities, experience on the existing project, and, eventually, the speed at which development will likely occur within each sprint are clear, making for good decisions about how much can or should be accomplished in a given amount of time. If you’ve worked on a project before, you might have a basic understanding of project management activities. In this table, you find a few traditional project management tasks, along with how you would meet those needs with agile approaches. Use the table to capture your thoughts about your experiences and how agile approaches looks different from traditional project management. Contrasting Historical Project Management with Agile Project Management Traditional Project Management Tasks Agile Approach to the Project Management Task Create a fully detailed project requirement document at the beginning of the project. Try to control requirement changes throughout the project. Create a product backlog — a simple list of requirements by priority. Quickly update the product backlog as requirements and priorities change throughout the project. Conduct weekly status meetings with all project stakeholders and developers. Send out detailed meeting notes and status reports after each meeting. The development team meets quickly, for no longer than 15 minutes, at the start of each day to coordinate and synchronize that day’s work and any roadblocks. They can update the centrally visible burndown chart in under a minute at the end of each day. Create a detailed project schedule with all tasks at the beginning of the project. Try to keep the project tasks on schedule. Update the schedule on a regular basis. Work within sprints and identify only specific tasks for the active sprint. Assign tasks to the development team. Support the development team by helping remove impediments and distractions. On agile projects, development teams define and pull (as opposed to push) their own tasks. Project management is facilitated by the following agile approaches: Supporting the development team Producing barely sufficient documents Streamlining status reporting so that information is pushed out by the development team in seconds rather than pulled out by a project manager over a longer period of time Minimizing nondevelopment tasks Setting expectations that change is normal and beneficial, not something to be feared or evaded Adopting a just-in-time requirements refinement to minimize change disruption and wasted effort Collaborating with the development team to create realistic schedules, targets, and goals Protecting the development team from organizational disruptions that could undermine project goals by introducing work not relevant to the project objectives Understanding that an appropriate balance between work and life is a component of efficient development

Article / Updated 01-23-2024

Agile approaches focus on customer satisfaction, which makes sense. After all, the customer is the reason for developing the product in the first place. While all 12 principles support the goal of satisfying customers, principles 1, 2, 3, and 4 stand out for us: (1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. (2) Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. (3) Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. (4) Business people and developers must work together daily throughout the project. You may define the customer on a project in a number of ways: In project management terms, the customer is the person or group paying for the project. In some organizations, the customer may be a client, external to the organization. In other organizations, the customer may be a project stakeholder or stakeholders in the organization. The person who ends up using the product is also a customer. How do you enact these principles? Simply do the following: Agile project teams include a product owner, a person who is responsible for ensuring translation of what the customer wants into product requirements. The product owner prioritizes product features in order of business value or risk and communicates priorities to the development team. The development team delivers the most valuable features on the list in short cycles of development, known as iterations or sprints. The product owner has deep and ongoing involvement throughout each day to clarify priorities and requirements, make decisions, provide feedback, and quickly answer the many questions that pop up during a project. Frequent delivery of working functionality allows the product owner and the customer to have a full sense of how the product is developing. As the development team continues to deliver complete, working, potentially shippable functionality every four to eight weeks or less, the value of the total product grows incrementally, as do its functional capabilities. The customer accumulates value for his or her investment regularly by receiving new, ready-to-use functionality throughout the project, rather than waiting until the end of what might be a long project for the first, and maybe only, delivery of releasable product features. This table shows some customer satisfaction issues that commonly arise on projects. Use the table and gather some examples of customer dissatisfaction that you’ve encountered. Do you think agile project management would make a difference? Why or why not? Customer Dissatisfaction and How Agile Might Help Examples of Customer Dissatisfaction with Projects How Agile Approaches Can Increase Customer Satisfaction The product requirements were misunderstood by the development team. Product owners work closely with the customer to define and refine product requirements and provide clarity to the development team. Agile project teams demonstrate and deliver working functionality at regular intervals. If a product doesn’t work the way the customer thinks it should work, the customer is able to provide feedback at the end of the sprint, not before it’s too late at the end of the project. The product wasn’t delivered when the customer needed it. Working in sprints allows agile project teams to deliver high-priority functionality early and often. The customer can’t request changes without additional cost and time. Agile processes are built for change. Development teams can accommodate new requirements, requirement updates, and shifting priorities with each sprint, offsetting the cost of these changes by removing the lowest-priority requirements — functionality that likely will never or rarely get used. Check here for a blank template of this agile form. Agile strategies for customer satisfaction include the following: Producing, in each iteration, the highest-priority features first Ideally, locating the product owner and the other members of the project team in the same place to eliminate communication barriers Breaking requirements into groups of features that can be delivered in four to eight weeks or less Keeping written requirements sparse, forcing more robust and effective face-to-face communication Getting the product owner’s approval as functionality is completed Revisiting the feature list regularly to ensure that the most valuable requirements continue to have the highest priority

Cheat Sheet / Updated 02-06-2023

In today’s time-pressured, cost-conscious global business environment, project management skills are essential. This Cheat Sheet offers you some key pointers to maximising your effectiveness in project management.

Cheat Sheet / Updated 10-26-2022

Scrum ensures transparency, inspection, and adaptation to enable a focus on continuous improvement, scope flexibility, team input, and delivering quality products. Scrum aligns with the values and principles of the Agile Manifesto, which focus on people, communications, the product, and flexibility. This Cheat Sheet outlines the main principles of the scrum project management method.

Article / Updated 09-16-2022

You don’t have to wait until your multi-vari data are collected to start creating the multi-vari chart for Six Sigma. Instead, you can build the chart, incrementally, adding more to it as you collect more data. Multi-vari charts can be drawn by hand; in fact, the process operators themselves can create them, providing those folks with a critical opportunity to invest themselves in the discovery of the root cause and the development of the solution. A multi-vari chart looks pretty much like any other two-axis plot, with time moving from left to right on the horizontal axis and the measured process output metric plotted against the vertical axis. The multiple measurements of each unit are plotted together. Consecutive unit groupings move from left to right over time. A break in the horizontal progression of the chart indicates a temporal break in the process sampling. The multiple measurements taken on each unit are plotted as circles. A slightly modified circle designates the first, second, and third within-unit measurements. A solid line connects the multiple measurements within each unit and graphically indicates the magnitude of variation originating within each unit — the variation contribution from positional factors. An average point is plotted for each unit grouping. These unit averages are drawn as squares. If the multi-vari chart is drawn by hand, this average can be estimated. The average isn’t the center point between the maximum and minimum unit measurements; instead, think of it as the “balance point” between all the unit measurements. A long-dashed line is drawn connecting the averages of consecutive unit groupings measured. The up-and-down variation of this connecting line indicates the magnitude of variation between units, or the contribution of cyclical variation factors. A mark is plotted to show the overall average of the set of consecutive units measured. A short-dashed connecting line is drawn between the overall average points. The up-and-down variation of this connecting line indicates the magnitude of the variation between long breaks in time, or the contribution of temporal variation factors. Vertical lines are drawn along the horizontal axis to indicate the end of one temporal set of measurements and the beginning of the next. Each vertical divider embodies a relatively long duration of unmeasured process execution time. The sampling pattern repeats itself for three temporal occurrences. A typical multi-vari chart would continue for more temporal occurrences, always until enough process data are captured to match the historical levels of variation known to exist in the process. Each temporal occurrence contains the measurements of three consecutive units. Each cycle should contain at least three consecutive units, but up to five or six may be necessary. Each unit consists of three measurements of the same process characteristic. As with the temporal occurrences, having up to five or six measurements is sometimes useful. Interpreting a multi-vari chart To determine which category of input variable drives the performance of your process output, all you have to do is graphically decide which of the three types of variation — positional, cyclical, or temporal — displays the greatest magnitude of variation in your multi-vari chart. You can compare the variation types by homing in on each one separately. The vertical range of the positional variation — indicated by the height of the gray boxes— graphically depicts the magnitude of the process variation stemming from positional input factors. The vertical range between the unit averages — indicated by the height of the gray boxes — graphically depicts the magnitude of variation coming from cyclical factors. The vertical range between the temporal averages — shown again by the height of the gray box — graphically highlights the magnitude of the variation coming from temporal factors. Temporal factors are those that only change their input value across larger gaps of time but not within single units and not between consecutive units. You can see that the vertical magnitude of the cyclical variation exceeds that for the positional or temporal categories. That result is the voice of the process telling you that the real root cause of your process performance is associated with some factor whose input value changes between production or creation of consecutive units. The multi-vari chart proves that all other factors that change input value within single units or change input value over longer times don’t exert a significant influence on the performance of the process.

Article / Updated 08-19-2022

The pressure of having to complete a project with little time and few resources often causes people to cut corners and ignore certain issues that can significantly affect a project's chances for success. Avoid the following common pitfalls and instead address the issues early in the project to help reduce their possible negative impacts: Framing vague project objectives: Project objectives are the results that must be achieved if the project is to be successful. The more specific the objectives, the easier it'll be for you to estimate the time and resources required to achieve them and the easier it'll be for you and your audiences to confirm they have been met.Be sure to include measures (the characteristics of an objective you'll use to decide if it has been achieved) and specifications (the values of the measures that you believe confirm that you have successfully achieved your objectives). Overlooking key audiences: Be sure to determine your project's drivers (those people who define what your project must achieve to be successful) and its supporters (the people who make it possible for you to accomplish your desired project's objectives). Important drivers who often get overlooked are the ultimate end users of your project's products. Failing to document assumptions: People almost always make assumptions regarding their projects; however, they often fail to write them down because they figure everyone else is making the same ones. Documenting your assumptions allows you to confirm that all people are operating under the same set of assumptions and reminds you periodically to check whether project assumptions have been confirmed and new ones have been made. Backing in to project schedules: Backing in to a project schedule entails trying to determine the time and resources you feel would enable you to achieve project success while ignoring the question of how likely it is that you'll be able to get the required amounts of time and resources.Instead of backing in, consider the time and resources that you realistically feel you would be able to secure and to explore different ways of using them to increase your chances of being able to successfully complete your project. Not getting key commitments in writing: Not putting commitments in writing increases the chances that what people intended to commit to was different from what you thought they did commit to. In addition to increasing the accuracy of communication, writing down commitments helps those who made them to remember them and encourages people to modify the written statements when necessary. Failing to keep the plan up-to-date: If a project is being run correctly, you and your team members should frequently consult the most current version of the project plan to confirm what each team member hast to do to produce the intended results. Not keeping the plan up-to-date means you have no reference explaining what people should be doing to successfully perform the required project work. It also suggests that adhering to the most recent version of the project plan isn't really that important, a belief that significantly reduces the chances of project success. Not having formal change control: Failing to follow a formal process for evaluating the effect of project changes increases the likelihood that important consequences of those requested changes will be overlooked when assessing the potential effects of those changes. In addition, it makes it more likely that some of the people who will be affected by the changes may not receive timely and accurate information about what those effects may be. Not communicating effectively: Problematic communications increase the chances that people will work with different information when performing project tasks, as well as decrease team morale and commitment to overall project success.

Cheat Sheet / Updated 03-10-2022

PRINCE2 is an essential project management method, helping users organise, manage and direct their projects to time and within budget. This Cheat Sheet presents you with a few tips and wrinkles to get the best from PRINCE2.

Cheat Sheet / Updated 02-25-2022

Project 2019, the most recent incarnation of Microsoft’s popular project management software, offers a tremendous wealth of functionality. Microsoft Project 2019 however, probably isn’t like any other software you’ve ever used, so mastering it can seem a daunting process. This Cheat Sheet provides you with tips and tricks for doing what you do every day as a project manager.

Cheat Sheet / Updated 02-22-2022

Successful organizations create projects that produce desired results in established time frames with assigned resources. As a result, businesses are increasingly driven to find project managers who can excel in this type of work environment. To get started in project management, you should understand the phases of a project’s life cycle, processes involved in project management, and the basic tasks you’re expected to perform.

Cheat Sheet / Updated 02-18-2022

To understand how to apply Lean in any organization, you should know the basics: the principles, the definitions of value and waste, how to lead effectively, and how to define and improve the value stream. You should also be aware of how a Lean leader thinks and acts.