Use a Separate “Discovery Project” to Plan a Large Project

There are two reasons to create a Discovery Project. For very large projects, the planning work can become very lengthy and unfocused. Planning the work for very large projects may take enough time that it should be structured as a project itself. This is one reason to define a separate Discovery Project.

Second, some projects are hard to plan because there is so much uncertainly. Rather than try to set up a large project with so much uncertainty, a separate smaller discovery project can be established.

The purpose of the discovery project is not to complete the entire project - only to complete the planning portion for the larger project. The final deliverable for a Discovery Project is a completed Project Charter, Project Management Plan, budget and schedule for the subsequent large project. All the other project deliverables will be produced as a part of the next follow-up project.

Discovery Projects, like all projects, come in different sizes. The Discovery Project itself need to be chartered, scheduled and managed like a project. Smaller Discovery Projects may just need a simple service request to begin. A larger Discovery Project will be managed as any larger project with its own schedule, budget, Charter, etc.

When the Discovery Project is completed, the Charter, schedule, budget and Project Management Plan will need to be approved by the sponsor. Once they are approved, the Discovery Project can end, and the following, larger project can begin.

An advantage to the Discovery Project is that you don't need to deal with the uncertainly of the large project at one time. Instead you will have two discreet steps - the smaller Discovery Project and then the more well defined larger project.

Remember as well that the Discovery Project completed the planning phase for the larger project. Therefore, when the larger project is ready to begin, it will not need to go through planning again. The larger project can start directly in the lifecycle phases. (Of course, you still need to manage and close the larger project, but the planning process can be skipped.)

Sometimes the planning for very large projects can drift and become unfocused. Managing the planning process as a Discovery Project brings clarity and focus to the purpose and allows you to complete the planning in a rigorous manner.

How Do You Handle Projects With Predetermined End-dates (Timeboxing)?

In a perfect world, your project schedule and completion dates would be derived based on the amount of work to be done and the number of resources available. As you know, that is not always the case. Sometimes when the project is assigned, it already has a targeted end date. For instance, the end-date may be determined by a government regulation, a scheduled event or to coincide with another company initiative. This situation is referred to as a "timebox", meaning you have a fixed amount of time to get the work done and the end-date is “boxed” in.

There is nothing wrong with having a fixed end-date. It can give everyone on the team a sense of urgency and focus. There may be a problem, however, if the project manager and team do not think they can get the work done by the deadline. In that case, the project manager needs to raise this as a risk. Potential risk plan actions include:

• Assigning more resources to the project. Too many resources may have diminished value but this is usually the first place to start.
• Having the team work overtime, with the understanding that overtime itself has a diminishing return, and that long-term overtime can actually have a negative effect.
• Working with the stakeholders to scale back the scope. This may include removing entire deliverables or functionality from required deliverables.
• Determining whether some required deliverables and features can be delivered later than the due date. For example, a 90% solution may be viable at the due date, with the additional work completed soon after.

Important -  Estimate the Amount of Schedule Risk

Even if your manager or sponsor has given you a fixed end-date, it is important to carefully build the schedule first as if you did not have the fixed end-date. If you do this first, it will give you a sense for how realistic it is to hit the fixed date. For example, let’s say you have a project that has to be completed in nine months. If you first create a “normal” schedule that shows the project will be complete in 9 ½ months, it would not be too much of a stretch to think you could complete the work in nine months. However, if you create a “normal” schedule and it shows the end date at 13 months, you will understand the difficulty and the risk associated with trying to get all of the work completed in the nine-month timebox. This does not mean that you will not have the nine month deadline. However, it gives you more information to have a fact-based discussion on the project risks and options that are available to you.  

Is Your Project Even Feasible? Here is How to Find Out

 Most people are aware of a Business Case. The Business Case allows you to define a project at a high-level, yet with sufficient enough detail to know whether the organization wants to provide funding. However, sometimes the sponsor is not certain of the costs and benefits, or even if the project is feasible. This is a good time for a Feasibility Study.

A Feasibility Study is used to explore whether a project makes sense or not. The Feasibility Study looks at more than cost and benefit. It looks at whether the project is feasible in a number of areas. 

There are a number of areas of feasibility that should be analyzed.

1. Technical. Is the project technically feasible? If it is you should state any technical risks associates with the project.

2. Financial. Is the project financially feasible? This would be especially important if the cost of the project was material to your company. It is possible that a project could have a cost that is significant enough to put the entire company at risk. You may have the ability to budget for the project now, but you might also analyze what the impact would be of a significant cost overrun.

3. Operational. Can you operate the project solution? It is possible that the project itself is feasible, but you may have significant risk in being able to operate the solution after the project is over.

4. Geographic. Is the project feasible given the physical location of the project team or the customer?

5. Time. Is the project feasible given the amount of time it will require from the participants? This is a big worry on larger projects. You may have the budget to execute the project but you may realize you cannot free up the project team for enough time to execute the project.

6. Resource. Do you have the staff, equipment, supplies and other resources necessary to complete the project?

7. Legal. Are there any legal problems that will make this project unfeasible?

8. Political. Are there any internal (or external) political problems that will make this project unfeasible?

Recommendation. You may explore a number of alternatives for structuring the project before ultimately drawing your final conclusion and recommendation. The recommendation may be that the project is not feasible. The sponsor and management stakeholders may choose to accept the recommendation or move another direction.

If the project appears feasible, the sponsor would proceed to develop the Business Case based on the final recommendation. The Business Case should address the costs, benefits, risks, assumptions, and other information to finally determine if the project makes business sense.

Five Important Soft Tips for Managing Project Teams

Five Simple, Yet Important Tips for Managing Project Teams

You can have great project management processes on your project, but how are your people management skills? Getting buy-in from your team and keeping everyone on the same page is not easy. But if you can do these five things really well, your team can thrive.

1. Over-communicate

How often have you heard "I didn't know that" from someone on your team when you know the topic was recently discussed at a meeting you all attended? This is a common occurrence that has been the nemesis of many project managers. Take a lesson from product marketers. There is an adage that says someone has to hear something up to seven times before they take action on the message. I am not saying that you should communicate each message seven times. However, if the message is important, communicate multiple times in different mediums. For example, perhaps a critical message gets communicated by email, text and verbally at a team meeting.

2. Listen

Everyone likes to be heard. This is especially true when people are giving their opinions on how to do something. It's important for you to listen intently to everyone on your project team. Does this mean that you will do everything your team suggests? Of course not! That would be impossible as what one person suggests may be in direct conflict with someone else's suggestion. But, it does mean that you have taken the time to listen to someone's ideas, asked them questions, and then taken the time to explain whether or not their ideas will fit into the big picture of the project.

3. Stay grounded

Didn't you hate it as a kid when you were playing a game and the rules always seemed to change? It's your job as a project manager to create reasonable ground rules and make sure everyone plays by them. These reasonable ground rules include what reports are due and when, how disagreements or conflict will be resolved, expectations for individual performance, and when issues need to be escalated. One word of caution...keep ground rules to a minimum. You don't want to overwhelm your team with rules.

4. Adapt

According to the Tuckman model, teams form through a set of stages. These are typically forming (coming together), storming (initial conflicts), norming (things begin to smooth out), and performing (reaching a high-performing state). To effectively manage a project team it's important that you understand the behaviors, cares, concerns, and anxieties of team members in each phase and manage accordingly. For example, during the storming phase you will be serving as a moderator, facilitator, and possibly even mediator. You will be very hands-on to help teams get over their differences. However, if a team reaches the performing stage, you want to back off and give everyone their room and independence to get their work done with minimal intervention.

5. Empower

Here's a sure-fire way to get people to quit in frustration - give them an important task to do without the proper level of authority to get it done. You can inadvertently do this a number of ways. The first is by making them check back with you every step of the way to ensure they are making the right decisions. This is a morale-killer and screams "I don't trust you!" The second is to give them a task that is beyond what they can handle. You are setting them up for failure and embarrassment. Instead, and set them up for success by mentoring them through the process and build up their confidence.
...................
That's all there is. If you listen to your team, over-communicate, create and stick to clear ground rules, adapt your management style as the team evolves, and empower them to get things done you will find that your project team can't wait to work with you on the next project you manage.

Own and Address Problems that You Cause

Own and Address Problems that You Cause

No one is perfect. A project manager typically does the best job he can given the information that is available at the time. However, there are times when issues arise because of a mistake that the project manager makes. This could be a mistake in communication, a mistake in estimation, a mistake in understanding the project deliverable, etc. 

Issues management is normally a cold and logical process involving problem identification and resolution techniques. However, these specific types of issues can be especially difficult to resolve since the project manager may feel some defensiveness (and perhaps embarrassment) for having caused the problem to begin with. Sometimes that fact that the problem was caused by the project manager makes it difficult to address the problem openly and in a timely manner. If this happens to you, use the following steps to deal with it effectively.

1. Own the problem. This is where the "fess up" (slang term for "confessing") starts. You must first recognize the problem and own-up to the fact that you caused it. If you cause the problem but try to blame it on others, you will find that resolving the problem is much more painful for you. If you caused the problem, or if you were partially at fault, be mature and honest enough to own it.
2. Communicate openly. You may be surprised how liberating it can be to just come right out and say that you blew it! If you own and communicate that you made a mistake, others will no longer feel the need to play the “blame game†â€" you have already admitted it! Your team can move quickly into resolving the problem instead.
3. Resolve the problem coolly and calmly. Look for alternatives and resolve the problem using your normal issues management techniques. Don’t get caught up in the personal pain by acting defensive or by looking for ways that you can save face. Given the mistake made, look for the best resolution for your project.
4. Learn from the mistake. Generally each mistake you make can be turned into a learning experience. You can put better processes in place if that is appropriate. You can also take a personal key-learning and change your management processes (maybe even slightly) so that this type of problem does not occur again.

It is common for managers to state that the only positive to come out of a bad experience is that they learn not to do it again. It would be great if there were better places to learn than the “school of hard knocks. However, as stated earlier, none of us are perfect either. When you make a major mistake, own up to it and communicate quickly. Then figure out how to overcome the problem and make personal adjustments so that the problem never occurs again.

If you will handle problems like this you will generally find that people give you the benefit of the doubt, and in fact many will even admire you for the way you address these personal challenges.
..............................................................................
Strategic Planning for Smaller Organizations

Organizations set goals and strategies to define their desired future state. Everything else falls out from there - portfolios, programs, projects, operations, etc. The LEAD process works for organizations of all sizes - and scales down to small organizations.

• Learn. Assess current organization.
• Envision. Establish goals and strategies to achieve the future state.
• Act. Create an action plan to close the gaps.
• Deliver. Convert your action plans into the tangible projects.

Use Five Steps in a Comprehensive Training Approach

Training is usually provided as the project solution is about to be deployed. However, on many projects the team does not start thinking about training until the end of the project. This is much too late. The key to an effective training approach is to start the planning process early. If you wait to consider training needs until the end of the project, you will not have enough time to do it the way you would like.

Training has a mini-lifecycle of its own. Some organizations call this a "workstream". In other words, training is not project management work. It is done in the lifecycle. There are five main steps. 

1. Start with the strategy (maybe)

First think about whether you need a Training Strategy. You would want the strategy if your project is complex and there is a large training component. All strategy documents on a project are typically done up-front in the Analysis Phase. The strategy includes an understanding of the stakeholders, type of training needed, the desired outcome of the training, assumptions, risks and the overall training approach. 

2. Create an overall Training Plan (for sure)

The Training Plan is created during the Design Phase. If you have a Training Strategy, the Training Plan simply contains the additional details required to make the classes real. If you do not have a strategy, then the Training Plan typically has some initial aspects of the strategy, and then quickly gets into the details as well. The Training Plan would include a description of the classes, number of classes offered, timing, the delivery mode (in-person, virtual, e-class), content development process, etc.  

3. Develop the training content

You develop training content at the same time that you are developing the rest of the solution. Isn’t that a novel concept? 

4. Test the training content (optional)

You can test your training content and delivery in a controlled class delivery. The test training is offered to the internal team, or perhaps to an initial customer group as a pilot test. This serves as a test of the material and helps prepare the instructors so that they will be more comfortable delivering the training to customers.

5. Implementation

The training classes are delivered based on the timing specified in your Training Plan. You should have developed (and perhaps tested) your training content, and you should be ready to go regardless of when the actual training is needed.

Summary

What you see in this approach is that the training process follows a mini-lifecycle. You analyze (Training Strategy), design (Training Plan) construct, test and implement the training. This lifecycle allows you to have all of the components you need as you need them.

Use These Seven Steps for a Project Audit

In some cases, such as a government project, periodic audits may be called for as a part of the overall contract. The audit could also be described in the Quality Management Plan. An audit is conducted by a third-party. This third party could be any qualified person outside of the project manager and project team. In some cases, your organization may have a project audit specialist. It is possible that the Project Director or the Project Sponsor could also perform this audit. The outside party could be an outside contractor or consultant, but they do not need to be.

The audit itself focuses on whether effective project management processes are being utilized and whether the project appears to be on-track. A project audit asks questions about the processes used to manage the project and build deliverables. The audit can follow this process:

1. Notify the parties (Auditor) - The auditor notifies the project manager of the upcoming audit and schedules a convenient time and place. Other key stakeholders are notified of the audit as well.
2. Prepare for the audit (Auditor) - The auditor may request certain information up-front. The auditor might also ask the project manager to be prepared to discuss certain aspects of the project. This ensures that the actual meeting time is as productive as possible.
3. Perform initial interview (Auditor, Project Manager) - During the initial meeting, the auditor asks the appropriate questions to ensure the project is on-track. If there are any areas that are not on track, the auditor notes them as such.
4. Perform as many other interviews as necessary (optional) (Auditor, Project Team) - If the project is large or complex, the auditor might need to perform follow-up analysis. This includes meeting with other team members and clients, and reviewing further documentation.
5. Document the findings (Auditor) - The auditor documents the status and the processes used on this project against best practices. If the organization has standards and policies in place for managing projects, the auditor determines whether any of these are not being followed. The auditor also makes recommendations on things that can be done to provide more effective and proactive management of the project.
6. Review draft audit report (Auditor, Project Manager) - The auditor and the project manager meet again to go over the initial findings. This auditor describes any project management deficiencies and recommendations for changes. This review also provides an opportunity for the project manager to provide a rebuttal when necessary. The initial audit findings might be modified based on specific feedback from the project manager.
7. Issue final report (Auditor) - The auditor issues a final report of findings and recommendations. The project manager may also issue a formal response to the audit. In the formal response, the project manager can accept points and discuss plans to implement them. The project manager may also voice his disagreement with certain audit points, and explain his reason why. In these cases, the project sponsor and the project director (manager of the project manager) will need to decide if the project manager should comply with the recommendations or not.

Use These Seven Steps to Calculate Duration

When you build a schedule you need to understand how to estimate duration. If everyone worked eight hours per day, and was 100% productive for all eight hours, you could easily calculate duration by taking the number of effort hours, divided by the number of resources. For instance, if an activity was estimated at 80 hours, and you have one person assigned, and he works eight hours per day, the duration would be (80 / 8) = 10 days. Likewise, if two people were assigned full time, the duration would be (80 / 2 / 8) = 5 days.                           

However, that perfect productivity is not indicative of how work is actually performed. Therefore, you can convert effort hours to duration activities using the following process.

1. Estimate the productive hours per day

Normally the first step is to determine how many productive hours of work you can count on each person working per day over time. Using a factor of 6.5 productive hours per day will help you take into account socializing, ramp-up time, going to the bathroom etc.

2. Determine how many resources will be applied to each activity

In general, the more resources you can apply to activities, the quicker the activities can be completed. (These are called resource constrained activities.) You need to estimate how much duration can be saved with additional resources. Obviously two resources may be able to complete an activity faster than one person, but it may not be twice as fast. Similarly, a third person may allow the task to be completed sooner, but not in one-third the time. Each additional resource may shorten the duration incrementally - up to a point where additional resources actually will result in a longer duration.

3. Factor in available workdays

Take into account holidays, vacations and training.  This was not included in the productivity factor in the first item, since this non-project time can be scheduled and accounted for in advance. For instance, on a three-month project, one team member may be out for two vacation days, while another may also have ten days of vacation. To make your schedule more accurate, take into account any days that you know your team will not be available to work on the project.

4. Take into account any resources that are not full-time

Factor in any resources that are not full time. For instance, if you have a resource allocated 50% of his time, it will take at least twice as long to do any individual activity. If you have an activity that has an estimated effort of 40 hours, and you assign a resource that is only allocated 25% to your project, the resulting duration will be at least four weeks, if not more.

5. Calculate delays and lag-times

Some activities have a small number of effort hours, but a long duration. For instance, a deliverable approval may take one hour, but might take two weeks to schedule the meeting. You need to take this lag time into account for your estimated duration.  

6. Identify resource constraints

When you build your initial schedule, you identify the activities that can be done sequentially and those that can be done in parallel. If you have enough resources, all of the parallel activities can, in fact, be done in parallel. However, you can only do the activities in parallel if you have the right resources available at the right time. There may be a set of activities that can be done in parallel; however they need to be worked on sequentially because only one person has the right skills to do the work. Be sure to factor in resource constraints. This adds additional duration.

7. Document all assumptions

You will never know all the details of a project. Therefore, it is important to document all the assumptions you are making along with the estimate.

Use These Eight Sections for a Terrific Status Report

Use These Eight Sections for a Terrific Status Report

Why is it that most of us don't have a problem working 40-50+ hours a week taking care of our stakeholder's needs, and yet we have difficulty writing a decent status report? Yes, some people simply do not have great written communication skills. However, in most cases, the problems with communication are not a lack of skills, but a lack of focus. Many project managers do not appreciate the value of communicating proactively. When they do communicate, it tends to be short and cryptic, as if they are trying to get by with the minimum effort possible.

The key to communicating is to keep the reader as the focal point – not the writer. Try to think about what the receiver of the communication needs and the information that will be most helpful to them. Ask yourself whether the information on the status report is there to really communicate something valuable or is it just taking up space.

Typically the complete status report should include the following information:

• The basics. Project name / project manager / time period / project description: This is all basic information that just needs to be included each time so that people know what they are reading.
• Overall status indicator: Typically there is a very short indicator that reflects the overall status of the project. A common technique is with color codes such as green (on track), yellow (caution) or red (problems).
• High-level status summary: Provide summary information regarding the overall project. Make sure that the questions are worded in a way so that a project that is on-track will answer either all 'yes' or all 'no'. The questions are focused on the present and future state of the project – not the past. For instance,
  • Will the project be completed on time?
  • Will the project complete within budget?
  • Will the project deliverables be within acceptable quality?
  • Are project issues being addressed successfully?
  • Are project risks being successfully mitigated?
  • Are all client concerns being addressed successfully?
• Comments: Give more information on any questions above that were answered 'no'.
• Significant accomplishments this period: List major accomplishments from the previous reporting period.  If the planned accomplishments from last period were not completed this period, the project manager should provide comments as to why.
• Planned accomplishments for next period: List major planned accomplishments for the next reporting period.
• Additional comments or highlights: Comments in other areas that the reader should know that would not be reflected in the status report.
• Attachments: There are many other logs and reports that might be of interest to the reader. Potential attachments include the Issue Log, Scope Change Log, project metrics / statistics and earned value reports.

Writing good, effective and objective status reports requires focus and diligence on the part of the project manager. The purpose of the status report is to communicate the true nature of the project and manage expectations. Make sure that you communicate effectively so that the readers have a similar understanding of the project as you do.  

Use These Five Communication Techniques on Your Projects

Many people think "managing communication" is the most important of the project management processes. If you think about it, over half of the time you spend managing projects involves some element of communication. Here are five techniques to help you be more effective.

1. Use appendices for status report details. You want to focus on meaningful information in the status report. However, you may find that some of your audience finds meaning in the exceptions while others find meaning in the details. One way to satisfy both audiences is to write the formal Status Report as an exception-based document and include the details as appendices (attachments). If you are emailing the information, you could email the detailed logs and reports as separate documents.
2. Report less detail as you get higher in the organization. Always keep the organizational level of your audience in mind. The organization level helps you determine the level of detail that is required in the Status Report. For instance, your team members need information that is highly detailed and highly specific to the work they are assigned. The manager of the project manager needs to have information summarized and delivered at a higher level. The next higher manager needs information at a higher level still.
3. Use the best communication media. When you select the various types of communication that you need for your project, also determine the best medium for delivering the information. For instance:

• Status Reports. These do not have to be on paper. Depending on the person sending and receiving the information, the status can be communicated via voicemail, email, videoconference or other collaborative tools.
• Email. Use email for routine messages, information sharing and some marketing related messages. Spread these out so that you don’t inundate the same people over a short period of time.
• Voicemail. Use voicemail to leave simple messages to individual people or to entire departments. Complicated or long messages are not appropriate for voicemails.

These and other mediums can be used to communicate effectively based on the message and the audience.

Use green / yellow / red indicators to show project health. We refer to green/yellow/red colors as indicating the overall health of the project. "Health" takes into account schedule, budget and scope, but also quality, morale, risk and other project indicators. In our model, green means you are on track, red means you are in the ditch and you need to re-baseline and everyone else is yellow.

Place communication activities on your schedule. The project manager should treat communication events like any project deliverable. You should add the activities to the schedule and assign people and end-dates so that the team understands when the communication is expected and who is responsible for creating and delivering it.

There are many elements of communication that require soft skills such as leading, negotiating and providing performance feedback. But there are other elements that simply rely on having good processes and good techniques. The best project managers have both the soft skills and the good process skills as well.

Four Techniques to Manage Risk on Your Project

All projects have risks and the risks have the potential for negatively impacting the project. (I am not referring to opportunity (positive) risk.) You use risk management to determine the risks that are important enough to manage. The following four techniques will help. 

Include Budget and Schedule for Unknown Risks

Some organizations allow project managers to create a risk contingency budget at the start of a project to account for budget risk. The risk contingency budget is estimated by multiplying the probability and the cost impact of risks. For example, if a risk has a $1,000 impact to the project and a 20% chance of occurring, you would include 200 ($1,000 * .2) in your risk contingency budget. The full risk contingency budget is calculated by making this calculation across all known risk, and adding a further contingency to account for unknown risks. This technique is also referred to ad Expected Monetary Value (EMV).

You can do the same calculation with schedule risks by multiplying probability by the number of days that are at risk to create a risk contingency buffer at the end of a project.

If your organization does not allow a risk contingency budget and buffer, you would naturally account for risk uncertainly in your base budget estimates. For example, if your base budget is $200,000, but the project is risky, you might estimate the final budget at $250,000 to account for risks.   

Ask Team Members and Stakeholders to Help Identify Risks

If team members are familiar with the circumstances of the project, they can take an active role in identifying and evaluating project risks. Joint participation from the team can help identify project risks, lay out effective actions to manage the risk and provide consensus and buy-in for execution.

Weigh the Cost of the Risk Plan Against the Impact of Risk

The activities associated with managing risks have a cost. The project manager should make sure that the effort and cost associated with managing the risks do not exceed the impact to the project if the risk occurs. For high risks, this is normally not the case. However, for medium risks make sure that the costs of managing the risk is not more than the risk impact to the project.

Understand the Risk Tolerance Level in Your Organization

During the risk identification process, you will encounter many risks. Which ones do you think are important enough to manage? The answer says something about your risk tolerance.

Risk tolerance is usually cultural in an organization. Some organizations are bigger risk takers and will accept a higher level of risk on projects. They will also tend to have a higher threshold before they chose to manage a risk. On the other hand, some organizations are more risk-averse. They will tend to accept less risky projects and they will also tend to have a lower threshold to manage risks. 

It is important to know your organization's tolerance for risk to make sure you are not undermanaging or overmanaging risks.   

Add Green Thinking to Your Procurement Process

The TenStep model for sustainable project management (GreenPM®) integrates green thinking (“greenthink”) into every project management process. The point about green project management is not that you make every decision in favor of the one that is most environmentally friendly. The point is that you start to take the environment into account during the decision-making process. You might make most decisions the same as you do today. But there might be some decisions you would make differently.    

Procurement

Procurement refers to the aspects of project management related to obtaining goods and services from outside companies.

Green Procurement

There are a number of areas within procurement that can be enhanced to consider sustainability and help you establish a green procurement approach.

• Plan Procurements. Green procurement starts with the Procurement Management Plan. The Plan will incorporate green thinking. It is important to understand any organizational Environmental or Sustainability policies and standards you are adopting on your project. As you gather and rank the needs against which you will evaluate vendors, you can now include sustainability criteria that the vendors need to meet. You can also establish the weighting factors for these needs and ultimately rate the vendors on their ability to meet your environmental and sustainability requirements.
• Obtain Seller Responses. In your RFP, you may include information on your organization’s environmental focus (such as describing your GreenPM processes) and have the vendor comment on how they will align to these, or make a general inquiry regarding the vendor’s use of green processes. Each vendor should be able to explain and demonstrate how they help accomplish your environmental goals, possibly describing how they have completed similar goals previously.
• Select Sellers. Map the vendor capabilities against your requirements and weighting factors, including the environment requirements that you have established. Using GreenPM, it is possible that your vendor selection may result in a different vendor. For example, if your environment requirements are weighted highly, it is possible that there is a vendor with a significant focus in this area who ends up being your top ranked vendor.
• Administer Procurements. You should validate that the vendor is performing as agreed throughout the project. This includes confirming that the vendor is following their promised green practices and meeting any defined environment criteria for deliverable completion. Procurement audits can be one approach to validating the compliance to your expected standards and processes.

Procurement is not simple and organizations seek to continually streamline and improve their procurement approaches. Green procurement may add another dimension to improving procurement processes.  

Apply Project Management in a Scaleable Manner

Projects are how we do new things. This makes them different than operational work - which is the day-to-day running of the business. Other characteristics of a project include:

• Projects are temporary endeavors.
• All projects are unique. They may be similar to prior projects but they are unique in terms of timeframes, resources, business environment, etc.
• Projects result in the creation of one or more deliverables.
• Projects have assigned resources - either full-time, part-time or both. This is reflected in a true budget or an implicit budget based on allocated resources.
• Projects have a defined scope of work.

Projects can be one hour, 100 hours or 10,000 hours (or more). However, the level of project management varies according to the size of the project. For a ten-hour project, you 'just do it'. Any planning, analysis and design is all done in your head. A 100 hour project probably has too much work to plan and manage all in your head. For instance, you need to start defining the work and building a simple schedule. A 10,000 hour project needs full project management discipline.

We categorize projects into sizes of small, medium and large. We use effort hours as the key criteria for sizing projects. This seems to be a true factor that differentiates the level of complexity. The basic scale we use is as follows.

• Small project - less than 250 effort hours
• Medium project - between 251 and 2500 effort hours
• Large project - over 2500 effort hours

In your company, the effort hours for categorizing projects may be different. However, in general, smaller projects need less rigor and structure. Larger projects need more structure.

Five Important Things to Know About Critical Path

Some people think the critical path is where the critical work is performed. Similarly, it was just a few weeks ago that a project management stated that she needed to pick the "right" critical path for her project. Both of these definitions are incorrect.

Critical path refers to the longest path through the schedule and represents the shortest time it takes to complete the project. The work on the critical path might or might not all be "critical". The critical path is determined by the work and the dependencies of your schedule. You do not pick the "right" critical path.

The critical path is an important aspect of your project schedule. Here are five things to know about critical path.

1. Float refers to schedule flexibility

On every project, no matter how complicated, there are always some activities that can be started earlier or completed later without jeopardizing the final completion date. This flexibility between the earliest time an activity CAN be completed and the latest time when it MUST be completed is called "float".

2. The critical path has no float

Now let’s look at those activities where you do not have the flexibility in the start and end-dates. These activities cannot be completed earlier because they are pending the completion of another activity. They also cannot be completed later without causing all the succeeding activities to be late. All of these activities back up tightly against other activities that precede or succeed them. In other words, the critical path has zero float.

3. The critical path is the longest path

The various network paths in your schedule have various lengths. The longest path is the critical path. Since it is the longest path, every other path will, at some point, have to wait while the critical path work is completed. This "wait" time is the float.

4. You need to understand critical path to manage the project with precision

If the project is trending late it is very important to identify the critical path activities. Unless you are able to accelerate activities on the critical path, the end-date for the entire project will not change. Applying additional resources to activities that are not on the critical path will not affect the overall project end-date. Your chance to make an impact on the projected end-date relies on your ability to identify and shorten the critical path.

5. The Critical Path May Change

Given that there are many, many paths through the schedule, it’s possible for the critical path to change. For instance, say you have a project with a critical path (longest path) of 22 activities over nine months. Let’s assume that there is another path of work that has 19 activities and takes 8 ½ months. There are two weeks of float on this path. Let's say one of the activities on the 8 ½ month path ends up taking an extra four weeks. Because there was only two weeks of float in the path, it will now become the critical path and force the entire project to complete in 9 1/2 months.

You will not be able to calculate critical path unless you are sequencing all activities. However, all project managers should understand this concept - even if you are not able to actually calculate one for your project.

Use Two Criteria to Determine Your WBS Estimating Threshold

When you create a schedule you generally don’t know enough to enter all of the detailed activities the first time though. Instead, you identify large chunks of work first, and then break the larger chunks into smaller pieces. These smaller pieces are, in turn, broken down into still smaller and more discrete activities. This technique is referred to as creating a Work Breakdown Structure (WBS).

How small should the activities be before they do not need to be broken down further? This is referred to as your “estimating threshold”. For example, if your estimating threshold was 80 hours, you would continue to break the WBS into smaller entities until all work was less than 80 hours. No work would be left at a higher level.

There are two criteria for determining the threshold.

• Better understanding the work. If you leave schedule activities at too high a level it may not be clear what is required to complete the work. You need to make sure the work is granular enough that it is understandable and it is clear what is required to complete it. For example, if you assign someone an activity that is 240 hours, there may be a lot of work to do for completion, and it may be confusing. If you assign four activities of 60 hours each (or 6 activities of 40 hours each) it should be more clear what is expected for each piece of work.
• Better able to manage the work. When you assign work to a team member you don’t know for sure how he is progressing until the due date (or the completion date if it comes first). For instance, if you assign a team member a piece of work that is due in eight weeks, you are not going to know for sure whether the work is on time until the eight-week deadline. Until that time you can just approximate if it appears things are on schedule. However, eight weeks (or longer) is too long to wait to know for sure if the work is on track. A better approach is to break the eight-week activity into four two-week activities. Then you will know after two weeks if the work is progressing on time or not.

Activities that are to be worked on in the distant future may not be able to be broken down less than the threshold because there may be too much that is unknown about the work itself. The future work can be left at a level higher than the threshold. However, if you leave future work at a high-level, it is still critical to break the work into smaller pieces at least two to three months before you need to start executing the work. This is referred to as "rolling wave" planning. 

These two factors – understanding the work and your ability to manage the work effectively - should drive your decision on how small to make your activities.

Use Two Criteria to Determine Your Estimating Threshold

When you create a schedule you generally don’t know enough to enter all of the detailed activities the first time in sequential order. Instead, you identify large chunks of work first, and then break the larger chunks into smaller pieces. These smaller pieces are, in turn, broken down into still smaller and more discrete activities. This technique is referred to as creating a Work Breakdown Structure (WBS).

How small should the activities be before they do not need to be broken down further? This is referred to as your “estimating threshold”. For example, if your estimating threshold was 80 hours, you would continue to break the work into smaller entities until all work was less than 80 hours. No work would be left at a higher level.

You can use the following criteria as a rule-of-thumb. For a typical large project (say 5000 effort hours or more), any work that is greater than 80 hours of effort should be broken down into smaller pieces. Medium-sized projects (say 1000 effort hours) should have activities no larger than 40 hours. If the project is small (say 200 hours), you should break down the activities into work no greater than 20 hours. Remember that this threshold is an upper limit. You can break the activities down further if you want.

There are two criteria for determining the threshold.

• Better understanding the work. If you leave schedule activities at too high a level it may not be clear what is required to complete the work. You need to make sure the work is discreet enough that it is understandable and it is clear what is required to complete it. For example, if you assign someone an activity that is 240 effort hours, there may be a lot of work to do for completion, and it may be confusing. If you assign four activities of 60 hours each (or 6 activities of 40 hours each) it should be more clear what is expected for each piece of work.
• Better able to manage the work. When you assign work to a team member you don’t know for sure how he is progressing until the due date (or the completion date if it comes first). For instance, if you assign a team member a piece of work that is due in eight weeks, you are not going to know for sure whether the work is on time until the eight-week deadline. Until that time you can just approximate if it appears things are on schedule. However, eight weeks (or longer) is too long to wait to know for sure if the work is on track. A better approach is to break the eight-week activity into four two-week activities. Then you will know after two weeks if the work is progressing on time or not.

It is possible that activities that are to be worked on in the distant future may not be able to be broken down less than the threshold because there may be too much that is unknown about the work itself. Work that is way out in the future can be left at a level higher than the threshold. However, if you leave future work at a high-level, it is still critical to break the work into smaller pieces at least two to three months before you need to start executing the work. This is part of rolling-wave planning. 

These two factors – understanding the work and your ability to manage the work effectively - should drive your decision on how small to make your activities.

Agile in Practice – Four Reasons to "Build for Today"

Agile in Practice – Four Reasons to "Build for Today"

One of the philosophies of Agile projects is to "build for today." In other words, you should design, build and test only what is necessary to meet the needs of the user stories that are selected in the current iteration.

In some respects this goes against the intuition of many team members that feel it is more efficient in the long-term if they take into account potential future requirements. The thought is that you should build to support this future functionality "while you are there" and then later when the requirement is actually selected you can finalize the work with much less effort.

In the Agile model this is generally seen as a false tradeoff for four reasons.

1. First, the time it takes to design, build and test to support future features will mean that you cannot get as much done in the current cycle. You are supporting fewer current, concrete, high-priority requirements in exchange for vague, distant        potential future requirements. This is not seen as a good trade-off.
2. Second, it is possible that this extra, future functionality will never be needed or requested. The customer may have requested this future functionality in a traditional project, but in an Agile project, the difference between "wants" and "needs" is much more focused. Who knows if the extra functionality will make it into a future iteration? The world is full of systems functionality that is written into programs but never utilized.
3. Third, it is very possible that you may not implement the future requirement correctly anyway. The product owner will not discuss it or test for this future condition. Even if a future requirement seems simple and fully understood, it is possible for misunderstandings and errors to occur. Then you are out-of-synch trying to test and debug problems that should not even be a part of this iteration. Each cycle will also have its own challenges. You don't need to compound things by introducing problems that are not a part of this release.
4. Fourth, if the extra functionality is needed in the future, it will have its turn in a future cycle. When the functionality is chosen, the work will be constructed and tested. In an Agile project, you will likely visit the same sections of the solution multiple times. You don't have to worry about building extra functionality "while you are there" because it is very likely you will "be there" many more times before the project is completed.

This philosophy should be applied for process functionality, performance, security, etc. The "build for today" approach is also an example of "minimally sufficient," which is another Agile philosophy. You want to make sure that you do everything required to support the customer needs, but no more.

Two Techniques for Qualitative Risk Analysis

After you identify project risks, you need to analyze them to see which ones are important enough to manage. The most common form of analysis is called qualitative risk analysis. This is referred to as “qualitative” since it is a quick approximation of the risk severity and does not reflect the rigor of a detailed, numerical analysis. The overall risk level can be as simple high, medium, or low (or even high/low), depending on the severity of impact and the probability of the event occurring.

There are many techniques for performing qualitative risk analysis using simple tables. Here are two examples that are fairly common.

High, Medium, Low Table

For example, you can use a table like the one below as a starting point. It helps identify high, medium and low level risks by looking at the probability of the occurrence and the overall impact to your project. For instance, a highly likely / high impact event is obviously a high risk. Likewise an event that has a low impact to your project, and has a low likelihood of occurrence anyway, is obviously a low risk. The other combinations fall somewhere within these two extremes.

Severity of Risk Impact / Probability of Risk Occurring	Overall Risk
High negative impact to project / Highly likely to occur	High
High negative impact to project / Medium likely to occur	High
High negative impact to project / Not likely to occur	Medium/Low
Medium negative impact to project / Highly likely to occur	Medium
Medium negative impact to project / Medium likely to occur	Medium/Low
Medium negative impact to project / Not likely to occur	Low
Low negative impact to project / Highly likely to occur	Low
Low negative impact to project / Medium likely to occur	Low
Low negative impact to project / Not likely to occur	Low

Ignore, Caution, Respond Chart

A second technique uses a simple table that provides guidance on whether you should respond to a risk.

Probability -> Impact	Low	Medium	High
Low	Ignore	Ignore	Caution
Medium	Ignore	Respond	Response
High	Caution	Response	Response

The green boxes represent a combination of probability and impact that you may safely be able to ignore. The red boxes represent combinations that need to be managed. The yellow box represent risks that should be evaluated individually to determine if you should respond or not.

Summary

These are examples of techniques used to analyze project risks. There are many other techniques as well. The point is that qualitative risk analysis relies on subjectivity to determine whether a risk is worth managing or not. For the vast majority of projects this subjective decision is good enough.