Project Management Knowledge

Simply explained by a PMI-certified Project Manager

Archives for November 2010

What Exactly Is Scrum And Is It For Everyone?

· · Leave a Comment

The concept of Scrum was invented for use in software development in the 1980s. It took a while for the concept to catch on in project management circles, but the idea has evidently stood the test of time. Now, even PMs far outside of the software industry have at least heard of this iterative method for project execution. There is actually an entire website (scrumalliance.org) devoted entirely to the exploration and further development of this concept.

Scrum Basics

The Scrum approach is often praised for its simplicity, agility, and results-oriented focus. Proponents of this methodology place a high value on collaboration, function, and flexibility over more traditional concerns like detailed documentation and plan adherence.

The actual project management process involves 3 sets of players. The Product Owner is the individual who ensures that the project outcome has real world value to stakeholders such as customers and the business organization as a whole. The ScrumMaster oversees the team to facilitate productivity and resolve any conflicts/roadblocks that may keep work from getting done. The Team is responsible for performing the project work as well as determining the processes by which the work is accomplished.

Step by Step

The Product Owner is responsible creates a product backlog that lists the work product items desired in order of priority. The Team selects a few items from the top of the list that will be addressed in a short burst of focused work activity called a “sprint”. The team is responsible for coming up with a realistic plan for how to achieve these project objectives quickly. This work period is short (less than a month). The team gathers once per day for a Scrum meeting to evaluate progress and make any necessary adjustments in their approach to achieving the sprint goals. The ScrumMaster referees the overall process as needed to keep the team on track. At the end of the sprint, the work product should be complete and fully functional. The sprint and its outcome are reviewed to capture any lessons learned. Then the whole process begins again with the next batch of items from the product backlog.

Can Any Project be a Scrum Project?

With highly creative processes, Scrum has obvious advantages. It permits the project scope to be rapidly modified on an ongoing basis as collaborative planning sessions open up new avenues through which to achieve the project objectives. While it doesn’t have a lot of safeguards in place to keep costs and schedule within reasonable parameters, it does make an effort to ensure that whenever the project is terminated there is something of value to show for all that work.

Proponents of Scrum sometimes state that it can be used for any type of project at any scale. However, this is not necessarily true. For example, a project undertaken as part of a government contract could have very specific rules about milestones, accountability, deliverables, and documentation. This might not mesh well with the highly fluid nature of Scrum project management.

In addition, not every project team is the right fit for this process. Some employees would prefer to simply be given clear instructions to follow to accomplish their schedule activities. Finally, in some situations the nature of the desired end product is straightforward enough that scheduling daily meetings to reevaluate how the project work is getting done is simply not a reasonable use of time.

A Poor ‘Lessons Learned’ Approach Can Impact Actual Learning

· · Leave a Comment

Once a project is completed, it can be tempting to simply wash your hands and move on. Looking forward to the next thing down the line is usually much more exciting than reviewing what’s in the past. Sure, basking in the glow of a job well done feels good. But scrutinizing the things that didn’t go so well isn’t enjoyable. Nevertheless, documenting lessons learned and implementing them is a critical part of project management. How can you ensure that this task is done in a way that promotes learning rather than discouraging your team?

Build Good Capturing Habits

If your team hasn’t been collecting data throughout the project, you won’t have much to put in your lessons learned knowledge base at the end. By that time, much of the wisdom that was actually gained about successful and unsuccessful strategies has been lost. Trying to recapture all this information at the end of the project is a time consuming and flawed approach. It will make everyone feel overwhelmed and exhausted.

The initial project management planning stage is when a process for gathering lessons learned along the way should be determined. For simple projects, this may be as straightforward as instructing each team member to keep a journal documenting insights throughout the life cycle of the project. For more complex projects, this documentation responsibility may be bundled into another process such as Quality Management.

Be Careful With Phrasing

Remember that the next team you work with will be reviewing the lessons learned by the previous group. Plus, the current team will also need to go over these materials. This means the documentation should be carefully written to avoid placing blame on specific people if things went wrong during the project. That way, the process of review is less intimidating and uncomfortable for everyone. Any necessary discussions about individual errors should be done in private rather than being made a permanent record in the lessons learned database.

Here’s an example of the wrong way to write a lessons learned report:

“Project management assistant Gary Ross failed to coordinate with HR on a simple scheduling task. This created a serious delay of 2 weeks and probably cost the company a lot of money. This employee has been reprimanded and received remedial training on how to do his job properly next time.”

Here’s an example of a much better approach:

“An initial decision was reached regarding scheduling based on partial information that resulted in a delay of 10 working days. Further investigation revealed that pertinent information readily available from Human Resources was unintentionally overlooked in the decision making process. Future schedule planning will include a consultation with HR to ensure more accurate results.”

As you can see, using a passive voice in writing makes it easier to achieve the objective of teaching in this situation. It is possible to outline the known facts about a mistake and how it will be avoided in the future – which is really the important information – without publicly shaming anyone. This is key if you want your team to be forthcoming about their mistakes in the future.

On the other hand, you can mention specific team members who contributed lessons learned about highly successful strategies. It’s a great way to recognize individuals who have done an outstanding job. Team members are more likely to participate eagerly in the review process when they know that this is where their achievements will be recorded for the purpose of improving future projects. In effect, they get to be the teachers!

Building A Qualitative Risk Analysis Matrix

· · Leave a Comment

The predictive skills required to carry out project management are nowhere more apparent than in the development of a probability and impact matrix. The inputs developed for use in creating this seemingly simple rating system require a great deal of expertise in qualitative risk analysis. Generally, a large number of team members (and some outside sources) must be tapped to generate a comprehensive and realistic list of risks. This is just the start since each risk event must also be evaluated to determine how likely it is to occur and how much damage it is likely to do.

Project Objectives and Risk Ratings

Each organization must determine its own standards and risk thresholds to develop a useful rating system. The probability of risk and the impact it may have on project objectives such as time, cost, and quality should be objectively determined and assigned a numeric or descriptive risk level. Some companies use a scale of one to ten; others use a ‘very low’ to ‘very high’ rating system. The simplest approach is often to assign a separate risk rating for each factor such as time, cost, and so forth as a first step. Determining the risk level of one factor (probability or impact) at a time on separate charts may also make things easier. The type of project management graph created at this stage is very straightforward to interpret since it can feature a simple x (column) vs. y (row) layout.

Probability & Impact Combined

Once a workable system has been developed for calculating risk ratings, these points can be plotted on a matrix. At this stage, it is possible to combine the ratings for probability and impact on the same graph to create an overall or “total” risk classification. This type of matrix may require the use of color coding or shading to offer a readily grasped visual for team members and other stakeholders. For example, probability may be plotted on one axis and impact on the other. Each point on the graph where these factors intersect may have an overall risk level represented by color. High probability/high risk areas on the matrix might be red, mid level risk areas yellow, etc.

A combined matrix is most useful in determining the amount of resources that should be directed at preventing a particular negative event from occurring. Events with a low probability may not require a large investment of time and funds to avoid even if they would have a fairly high impact. They may simply need to be monitored to see if the probability rating rises. On the other hand, events with a high probability and a low impact may be worth addressing immediately (if this can be done cost effectively) simply to keep things running smoothly.

Knowledge Preservation

The thought process used to arrive at an accurate rating assessment for each risk should be fully documented. So should a description of the anticipated outcome of each potentially negative event. This information is particularly important for the ongoing risk review process that should occur throughout the duration of the project. Having access to the data that was used to reach the initial set of conclusions helps reduce the time and effort required for re-evaluation later. With something as complex as risk analysis, it is very unlikely that the project management team will remember all the details without this documentation.

Procurement Strategies – Seller Selection

· · Leave a Comment

For project management specialists who will be closely involved in procurement, it is helpful to have a good grasp of the various factors in play in the seller selection process. This is especially critical for smaller organizations that may not have a separate Purchasing department staffed with expert buyers. PMs need to have the proficiency to make the best decision – and know what questions to ask each vendor. Here are several areas that may require review in order to make a realistic comparison between seller proposals.

  1. Price

This is the most obvious factor in most procurement decisions. However, it is easy to make the mistake of not comparing total prices between vendors. Some sellers will fail to disclose hidden costs such as environmental or shop fees, handling, materials surcharges, etc in their quote. In some industries, these added fees can represent a significant profit driver (even though the vendor will claim it is simply cost recovery). Every project management request for quotation (RFQ) should stipulate that quotes must contain a line by line breakdown of all costs including incidental fees.

  1. Shipping

The location of a vendor’s shipping facility in relation to your organization can seriously impact the cost of shipping and the required lead time for a component. These two factors should be weighted against one another to determine whether a quicker ship time has significant value given the project schedule. It is important to bear in mind that vendors often ship from a different location than their corporate headquarters. Vendors who are distributors rather than manufacturers may be reluctant to reveal the source of their components (so you can’t cut out the middle man). However, you should at least be able to obtain an actual zip code for the point of origin to assist you in evaluating shipping costs.

  1. Assurances

One factor that should be given significant weight is whether you have successfully conducted prior business dealings with a vendor. This is the best indicator of quality of parts/service and on-time delivery/completion. Entering a relationship with a new seller always carries a significant level of risk. Paying a higher price to do business with an established vendor may be the best option if an untried vendor’s failure to perform would seriously impact the outcome of a project.

  1. Simplicity

With a sole focus on price, it can be tempting to break up a procurement order into too many constituent pieces. Project management becomes exponentially more complex the more players there are in the mix. If quality and lead time are equivalent, bundling items to purchase from a single seller is usually preferable to purchasing each item from multiple sellers. Again, the ease of managing the procurement process should be given particular weight when this task must be handled by the project management team rather than a separate department.

Schedule Compression Methodology

· · Leave a Comment

Schedule compression is a technique used in project management to create output faster without changing the actual scope of a project. Sometimes, there is a tangible benefit to significantly shortening the project timeline. For example, this might be the case when:

  • A competitor is preparing to release a similar product or concept and your company wants to be first on the market
  • Anticipated changes in economic landscape, political climate or environmental conditions are likely to derail the project unless it is completed ASAP
  • A client is offering additional monetary incentive for a rush job
  • There are several subsequent, related projects planned which are dependent on the timely completion of the current project
  • Your organization is aware of the opportunity to bid on a new, highly lucrative project in the near future but doesn’t have enough resources to handle two projects simultaneously

In these situations, it makes sense to at least consider schedule compression.

Option 1

One potential approach is referred to as “crashing”. This involves weighing the additional costs associated with doing a rush job with the benefits of meeting the newly proposed deadline. There are both obvious and concealed costs involved in this project management practice. Expedited shipping for any materials used in manufacturing an item might be a readily apparent cost. The risk that the QC department may miss an important quality issue if they are rushed in their work is an example of a potential hidden cost.

The goal of crashing is to determine the perfect balance between shortening the schedule and keeping costs low. Sometimes the tradeoff is simply too costly and the idea of schedule compression must be abandoned entirely. Project managers should tread cautiously when the push for an earlier completion date is not coming from the same people who have the authority to approve increases in cost.

Option 2

Putting a project on the fast track is another way to achieve a more rapid output. This can sometimes be done when the resources that have already been approved are immediately available to be allocated as needed. This project management approach involves completing multiple phases of a project simultaneously instead of in sequence. Just like parallel processing increases the speed of computing, having several teams working on various work packages at the same time can cut schedule times significantly.

There are risks associated with fast tracking. For example, there is a greater chance of errors when schedule activities are started without the detailed information that would have been available if the team had followed the original project timeline. Mistakes that require work to be redone can end up increasing the time to completion and may negate the whole purpose of the schedule compression effort. The risk management plan should be fully reviewed before fast tracking is attempted.