Building High Performance Teams

What is a high-performing team?

It's a team that exceeds the goals you set by working hard and smart as a group, not individuals. It's a team that enjoys working together. Most teams do not reach the high-performing stage. That is why they are so special when you finally achieve this feat. You can help a team reach a high-performing state with a number of basic steps.

1. Plan What the Team Will Look Like

Before you bring on your first person, you need to document what it is that your team has to achieve and by when. This can be done through a project charter or another document that details what the team will achieve together.

But don't stop there. Think about the team culture you want to build, the dynamics of your team and how they should work together.

2. Add the Right People

Building the right team is harder than it looks. It's easy to recruit the wrong person, and it's even easier to build a team that doesn't perform well. Often you cannot pick and choose each team member. When you can, choose candidates that fit the job description, align with your personal vision for how the team will work together and want to work in a culture that depicts your vision.

3. Create a Team Culture 

If you've hired like-minded people, get them working together on tasks. Constantly change the people you pair up, so that people get to know others in the team. Strengthen the relationship between the team and your customers. Find opportunities to get the team socializing together.

4. Motivate the Team - and Yourself

A happy motivated team will always out-perform an unhappy unmotivated one. And it starts with you. Are you happy and motivated? Your motivation will rub off on your team. If you are motivated, focus on motivating your team. Use team building and group rallying exercises to get them pumped up. Tell them how proud you are to work with them. Help them understand why the goals are important and how every team member contributes to them.

Step 5. Recognize Accomplishments

People respond positively to positive behavior. So you need to constantly recognize achievement when it's due. Tell the team about an individual's success. Make them feel proud. Spread the love—don't focus on one team or person too frequently.

If you plan for success, recruit a great team, build a positive culture, motivate the team and recognize achievement, you'll build a healthy project team and boost your chances of success!

Ten Sure Signs Your Project is in Trouble

Many projects struggle. Sometimes the causes are subtle and complicated. Other times the causes are pretty straightforward. Here are ten reasons why projects struggle. If your project has one or more of these characteristics you can expect to struggle - maybe even fail.

1.      Insufficient resources. The project manager builds a schedule assuming a certain level of resources will be available. If you don't have the level of resources or budget you need, You are going to struggle. Be sure to tell your project sponsor quickly.

2.      Impossible deadlines. Sometimes a project is assigned with a fixed deadline that is impossible to achieve. Sometimes these projects are referred to as a "death march". The project manager should tell the sponsor at the start of the project and fight to have the deadline extended, the scope reduced or resources increased. You not only need to have sufficient time to deliver your project, but you also need contingency in case things take longer than expected.

3.      Not managing expectations. The project manager fails to communicate the true status of the project to the team and sponsor. So everyone thinks the project is going smoothly until the deadline is missed. You need to tell people early if it’s slipping. Don't hide it. By telling people you're running late, you give them the opportunity to help get it back on track.

4.      Lack of focus. The team doesn’t really know what is expected of them, so they lack focus. They are given a job to do but not told what is required and by when. Everyone in your team should have regular goals to meet, they should have deadlines and you should be monitoring their progress at every step in the journey.

5.      Low morale. The project team lacks motivation, so nothing is delivered on time. If you want someone to deliver within a set timeframe, then you need to motivate them to do it through reward and recognition. And you need to be highly motivated yourself. Only by being healthy, relaxed and truly motivated can you inspire others to be.

6.      Lack of sponsor support. The project manager gets very little support from their sponsor. There is no one available to help solve problems or provide further resource or money when it's needed. If you lack sponsor support, address it early. Be open and frank with them. Tell them what you need and by when.

7.      Scope creep. The scope of the project keeps changing, so you never really have a fixed set of deliverables. Every time it changes, you lose time and resource, so change control is critical. The scope needs to be clearly defined and then a process put in place to ensure that change requests are formally approved.

8.      The project is too long. The project timescale may simply be too long. Over time your customer's requirements will change, so you need to break your project into smaller chunks and deliver each as a project on its own.

9.      Lack of tools and processes. Not having the right tools to get the job done can also be a problem. Using good quality tools such as templates, processes and a project methodology will lead to project success.

Insufficient of customer involvement. Lack of customer involvement has proved fatal on many projects. You need to involve your customer throughout the project to ensure that what you are building will meet their requirements. Remember, only if your customer is truly satisfied will your project is a success.

Six Coding Techniques for Agile Projects

One of the philosophies of the Agile model is the importance of building workable code in short sprints on an ongoing basis. There are a number of techniques that are ingrained in the Agile model that result in more straightforward and elegant code. 

Code as simply as possible. Some programmers take pride in how sophisticated they can make the code. An Agile programmer instead takes pride in how simple the code can be to accomplish the expected result. This simplicity is the most effective over the long term. 

Build for today. Your code base should focus on fulfilling the user stories and requirements that are part of your current iteration. Do not add code to solve future user stories or potential functionality. These future features will be concentrated on when they are chosen in some future iteration. 

Code as flexibly as possible. At the same time that the code is simple, it also needs to be flexible. You want to be sure you don’t make decisions that are perfect for your first iterations, but then don’t allow you to easily add more and more features and functions in later iterations. Another Agile philosophy is to make decisions at the latest responsible time. This does not mean to procrastinate. It simply means to maintain options and flexibility as long as possible so that decisions can be made with as much information as possible. 

Document the code. If you are trying to track down problems in code, you are not going to be able to find the problem in a programmer’s manual. The only place you are going to track it down is the code. Even if the client asks you to investigate how a feature works, you typically cannot rely on an external programmer’s manual. The only way to know for sure is to check how the code works.

Since the code is the ultimate description of the code, it is important the code be understandable. This requires the code itself have plenty of comments. These comments don’t reflect the obvious, but are there to point out creative techniques or describe major sections of code that enable certain features and functions. The code also needs to be simple to review and to understand by others who will follow you. 

Share ownership of the code. In a traditional project, each programmer is responsible for certain programs and components. The programmer creates the code and unit tests it. Later, if there are bugs in the program, the initial programmer is responsible for fixing the errors. In an Agile project, the team takes collective ownership of the code. One programmer may create the code (or perhaps it was created by two people using pair programming), but anyone may be assigned later to update the code. The code may need to be updated because of new requirements in a later sprint or to fix a bug that was not uncovered earlier. Anyone – not just the original programmer – may be assigned. 

Refactor the code. When a programmer is assigned to an existing component, he has the flexibility (and the obligation) to look for opportunities to simplify or refactor the prior code base. The code will hopefully be more efficient and simplified by having multiple programmers work on it at various times during the project.

If you look at the total lifecycle of an application, only about small percentage of the cost and time is spent during the development project. The larger percentage is spent in the support and maintenance phase. If you build a good application, the code might run in production for ten years or more. Simple, straightforward and optimized code allows easier understanding, easier error fixes and easier enhancements over the entire lifecycle.

5 Steps For Managing Project Risk

This simple 5 step process will help you manage project risk easily.

Step 1: Where are the risks?

The first step is to list everything that could have an impact on whether your project is a success. Think about all the potential problems that you could come across during the project and write them all down. It helps to do this with your team, as they will see things differently to you.

Step 2: What is the impact?

Now you have your list of risks it's time to see what impact they would have if they happened. You'll have the full spectrum: risks that won't cause big problems and risks that could potentially force your project to stop.

Prioritize the list of risks based on the impact: the ones with the largest impact are the highest priority. These are the areas you should focus on right now. Look at each individual risk, but also look at the risk profile overall—do all these risks add up to make your project really risky or is it going to be a low risk initiative? Use ProjectManager.com to present your project's risk profile as a report or dashboard, as that makes it easy for executive managers to see where potential problems lurk.

Five Cool Things to Know About Action Items

An action item is an ad-hoc work activity that requires follow-up execution. By their nature, action items normally cannot be planned for in advance. They arise on an as needed basis during meetings or as a by-product of working on something else. There is no Knowledge Area in the PMBOK Guide for managing action items, but they can be important to the smooth running of the project. By their nature they generally fall under time management.

1.      An action item is assigned because there is not enough knowledge, expertise or time to resolve the item at the time it originally surfaced.

2.      Action items need to be assigned, worked on later and completed. (If they are not going to be completed, they should not be called action items. Instead, simply note that the item will not be completed.) Examples of action items include forwarding specific information to someone, arranging a meeting and providing a quick estimate on a piece of work. 

3.      Sometimes an action item is established to investigate an area where there may be a potential problem. Because of this, action items are sometimes called "issues". However, this is not right. An issue is a problem which will have a detrimental impact on the project if left unresolved. Issues are not the same as action items.

4.      Trivial action items may be tracked and managed with a standalone Action Item Log. If the action item came from a meeting, you can create a section in your meeting minutes for action items. These trivial action items are usually less than two hours of effort and are scheduled to be completed by the next meeting. If you use this technique you can start each meeting with a review of the prior action items to validate that they are completed and then cross them off the list. 

5.      If the action item is non-trivial (greater than two effort hours) you should add them as activities in the project schedule. A resource and end-date are assigned as well, and the activity is then managed and tracked as any normal schedule activity. This is the better approach to follow, because it keeps the work activities in one place and allows the project manager to enforce the discipline of knowing ‘if it’s not on the schedule, it will not be worked on.’ This approach also allows the project manager to see the impact of the action items on the schedule. For instance, you may have a small action item that is 4 hours of work. If you assign this action item to a person on the critical path, you will see the resulting delay to your project. This may result in you assigning the action item to someone else instead.

In many cases, action items are trivial in nature, but in other cases they can require substantial work to complete. Projects tend to generate lots of them and you need some method to track and close them to ensure the project work continues to run smoothly.

..................................................

Resource planning templates and more. Get your project started quickly with a pre-built set of great project management templates. Buy now and use immediately.

Is Technology Changing Project Management?

I was asked a while ago whether technology was changing project management. It seems like technology is changing faster and faster all the time. But is technology changing project management to any degree?

This is an interesting question. Certainly, there are a couple aspects of projects where technology comes into play. First, many projects are becoming more and more technically complex. This is true for many projects - IT, pharma, engineering, finance, etc. It seems like many projects have some tool or technology component. However, this is not a project management matter, but it is a characteristic of the products we are building and the project tools we are using. 

Second, the tools we use for project management are changing. This includes tools for  scheduling, risk management, communications and more. Client-server tools have

replaced mainframe tools, which have all been replaced by web tools. Today, many of the project management tools run in the cloud. The tools have also become more complex to satisfy the needs of project managers today.

There is a lot of discussion today about Agile methodologies. These rely on light processes to deliver solutions more quickly through short iterations. Many of these Agile projects are technology projects, but the project management approach is driven more by philosophy rather than by technology. In fact, the project management aspect of Agile actually discourages the use of software tools and focuses on simple manual processes.  

All that being said, in my opinion, the actual project management discipline has not changed that much based strictly on technology drivers. You still have to manage scope. You still have issues to resolve. You still have to manage risks, etc. The various aspects of planning and managing work as a project do not necessarily change based on the technology. For example, it is true that there are new technologies for helping you build and manage a schedule. But the basic mechanics of building and managing a schedule have not really changed.

There may be some aspects of communication that have been affected by technology. Technology has given us the ability to communicate faster and in more real-time. There are also better tools for collaboration and sharing. This may be an area where technology has affected to fundamentals of project management.

So, to answer the question from the beginning of the article - has technology changed project management? In my opinion - not so much. The nature of the projects themselves may be impacted by technology, but the fundamentals of planning, cost management, schedule management, risk management, scope management, etc. have not changed so much. Project management is process-driven. Although technology has impacted the automation and speed of these processes, I think the fundamental nature of project management has not been changed much by technology. 

.................................................................................

Study on Your Own with TenStep e-Classes - 20% Off

Learn at your own pace and when you have the time. Use coupon code "TS0020" for an instant 20% off.

Fundamentals of Project Management  |  Managing Small Projects  |  The Essence of Project Management  |  Fundamentals of Scheduling e-Class  |  Project Management for Managers

Check out the e-class library now.

5 Ways To Manage Your Time

You'll get more done in less time!

#1. Timesheets

First, think about where your time is going. Do you really know what you work on all day? Timesheets will show you exactly how much time you spend pulling together reports or responding to emails. Then there's the 5 minute break to check Facebook that turns into 20 minutes...

Start tracking your time so you know where it's going. This will help you prioritize and ensure you are self-aware when it comes to managing your time.

#2. Task lists

Many people get off to a slow start in the mornings because they are wondering what their priorities should be and thinking about what they should be doing. Task lists resolve this. A clear list will tell you exactly what you need to work on. If you add in a column for dates it will also tell you what needs to be completed by when, which is a huge help when it comes to scheduling the top priority tasks first.

The task list feature built into ProjectManager.com makes it simple to create and update your tasks from wherever you are. Even if you are travelling, if you've got an internet connection you can quickly add a new task to the list (or tick one off) with the handy mobile app.

#3. Milestones

Milestones are a good way to manage your time as they focus the mind! Put some milestones on your project plan and review them regularly. As you are coming up to the deadline, make sure that all your work is aligned with the objective of getting it done and hitting that date.

Most milestones relate to project tasks but you can also create personal milestones on your calendar to remind you about scheduled dates for other tasks on your task list.

#4. Automation

Project managers tell us that preparing reports is one of the things that takes the most time each month. There's getting status updates from team members, preparing the data, checking it, formatting it, reviewing statistics from other systems, then checking it again and sending it to the stakeholders. It takes forever!

Automate your reporting (and anything else) as much as you can. Set up templates that pull data from your project management software and show you status in real-time. Everything that is automated is one less job for you to do.

#5. Saying no!

Finally, say no! You don't have to do everything that is asked of you, and sometimes you simply can't take on more work. If you don't feel that you can say no to a request, ask your manager or project sponsor what they want you to drop. "I'm working on X, Y and Z right now. Which of those should I move to the bottom of the priority list so I can take on A and B as well?"

If it isn't feasible or reasonable to get everything done, then negotiate priorities with your stakeholders so that you aren't overloaded and they appreciate what can realistically be done in the time available.

Try these 5 tips for managing your time and see how many extra hours you can find in a day!

It's easy with ProjectManager.com. The system is fully automated and manages reports and timesheets for you. It leaves you free to work on critical project tasks and tick things off on your To Do list.

Take a Free Trial.

How Big is a Project in Your Organization?

Projects are not routine. They are managed differently than routine operational work. Projects have a start and end-date. There is a point in time when the work did not exist (before the project), when it does exist (the project), and when it does not exist again (after the project). This is the key determinant of whether a piece of work is a project.

Other characteristics of a project include:

·  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.

That being said, you need to be practical. In theory, projects can be one hour, 100 hours or 10,000 hours (or more). So, you must recognize that, although the creation of a small deliverable is a project, it does not need the structure and discipline of a much larger project. For a one-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.

Our model for scaling projects is to use a scale of small, medium and large. We use effort hours as the key criteria for sizing projects. This seems to be a true complexity factor. Duration is not a good factor since it varies depending upon the resources committed. For example, a 100 hour project could take 20 weeks if you can only spend five hours a week. The basic scale 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 very little rigor and structure. Larger projects need more structure.

Summary. The definition of a project covers work that could be as little as a minute. However, no organization is going to track one minute projects, or one hour projects. Even though these are all technically projects, your organization should have a minimum threshold that you use before you consider the work to be an official project. Our threshold is 250 hours. What is yours? 

..................................................

Project templates. Define and manage scope on your project - plus much more.Get your project started quickly with a pre-built set of great project management templates. Buy now and use immediately.

Two Major Elements of Project Scope

Defining scope is perhaps the most important part of the initial definition and planning process. If you don’t know what you are delivering and what the boundaries of the project are, you have no chance for success. If you have not done a good job of defining scope, managing scope will be almost impossible.

Most people understand what scope means, but many struggle trying to actually define the scope of a project. It is easiest if you remember there are two major aspects of defining scope on your project – deliverables and boundaries.

·  The deliverables. All projects produce deliverables. (These are sometimes called the "products" produced by the project.) Even if you are not sure what else to include in your scope definition, you should always include your deliverables. Understanding the deliverables you are building goes a long way to understanding the scope of the project. There are many deliverables that could be listed, but you should focus on the final deliverables of the project - not necessarily the internal deliverables produced as a part of delivering the final solution.  

·  Project boundaries. The scope boundary statements are used to define what is within the boundaries of the project and what is outside those boundaries. The more boundaries you can identify, the better off your project will be. You would not need to state that some aspect of the project was in-scope unless you could also contrast that with some aspect that is out of scope. The nature of a true boundary statement is that there is both an in-scope and a relevant out-of-scope counterpart. For example.  

o        The major life-cycle processes that are in scope and out of scope. For instance, your project may include the Analysis Phase only and not the Design, Construct or Test Phases. Or perhaps your project is performing research, but you are not going to develop the results. These would be examples of using boundary statements to clearly state what your project is responsible for, and what is out of scope. 

o        The organizations that are in scope and out of scope. In some cases, the organizations involved in the project help to define the boundaries. For instance, your project may be applicable to the Human Resources and Accounting Departments, but the Manufacturing Division might be out of scope. Or perhaps your project is only impacting the corporate office while the field offices are out of scope.

o        The major functionality that is in scope and out of scope. This might be a good boundary if you were delivering less than full functionality. For instance, decision support and management reporting might be in scope, while overnight batch processing might be out of scope. Or perhaps financial reporting is in-scope for your project, but Human Resources reporting is out of scope.

What do you need to remember? First - scope is defined as deliverables and boundaries. Deliverables are the things you build during the project. Boundaries are statements that describe the project in terms of in-scope and out-of-scope. 

..................................................

Define and manage scope on your project - plus much more. Get your project started quickly with a pre-built set of great project management templates. 

How to Work More Effectively

With more teams working in different offices, travelling and working at home these days, the chances are that some of your team members don't work in the same building as you from time to time. This can present a challenge: how can you work with them when you can't meet them physically?

Online collaboration tools are the easiest way to work effectively with people on a project, wherever you are. There are even benefits if you are all based in the same office space. So here are 5 tips to help you...

Tip 1: Keep all your discussions online

One of the most effective ways of working is to move everything online. Online collaboration software can help you do this, as it is designed for running projects on the web. The benefit of having all your project information and discussions online is that everyone can see the latest status at any time. You can even move your emails online into the software that you are using so that the whole discussion trail is in one place.

Tip 2: Use instant messaging

Instant messaging is great for getting the answer to a quick question, or checking if one of your colleagues is available for a longer discussion. You can archive your messaging trail securely online so that if you need to refer to it later it's there in your project files. It's faster and easier than email and once you start using it you'll never look back.

Tip 3: Share pictures

Do you know what all your team members look like? That might sound like a silly question, but if you are working with colleagues overseas or even in a different office, you may never have met them. Even if you have met them, chances are someone on your team has only ever talked to them on the phone. Upload photos to your team area so that you can see each other. It's easier to collaborate if you can put a face to a name!

Tip 4: Upload files

Stop sending huge email attachments by uploading all your core project files to a central online location. Using a document repository like this means that everyone always has access to the latest version, which can be a massive time-saver. It also means that people don't get frustrated looking for the latest copy and your IT department will be very happy that you aren't using your inbox as a document store!

Tip 5: Share calendars

It can be difficult to collaborate with team members if you don't know where they are. Sharing calendars means you can check if they are on leave or out of the office, and schedule meetings appropriately. You can also put key project milestones in the calendar so that everyone knows what is coming up without having to look at the project schedule. Make sure that you keep your own calendar up-to-date as well and include all the national holidays that are appropriate for your international team members, so you know when their offices are likely to be closed.

Using the collaboration features of ProjectManager.com is the easiest way to work effectively with your project team. Start discussions, share files, allocate tasks to each other and use instant messaging. As it is all online, you can store the conversations securely in your project files.

Take a Free Trial now.

Four Techniques to Manage Risk on Your Project

All projects have risks and the risks have the potential for negatively impacting the project. You use risk management to determine the risks that are important enough to manage. The following four techniques will help. 

Try to Include Budget and Schedule for Unknown Risks

A project manager can request additional budget and schedule to account for known risks at the beginning of a project. Of course, the risk contingency does not include the full impact of risk. Instead you multiply impact by the percentage likelihood for all high risks. Then add the numbers to come up with a risk contingency budget and schedule.

However, risk identification is not something that only happens at the beginning of a project. The project manager assesses risks throughout the project.  Therefore, it makes sense to include time and budget for unknown risks as a part of your estimating process. If you do an effective job of periodically reassessing risks, you may find new risks to manage that were not included in the original risk contingency budget. You can include some additional contingency budget and schedule for these as well.

If your organization does not allow a risk contingency budget, you would naturally account for risk uncertainly in your base budget estimates.  

Include Team Members in Risk Identification

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 Management Plan Against the Level 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 may encounter many risks that have some likelihood and impact to the project. 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.    

..................................................

Use the "Gold Standard" for Project Management. MPMM is used by tens of thousands of customers around the world. Take a test drive with the free trial download. NOW with extra program management and IT development modules.

Download the free trial

Buy MPMM today.

Five Things to Know About Critical Path

Critical path refers to the sequence of activities that must be completed on time for the entire project to be completed on time. It 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 path has zero float.

The critical path consists of the longest sequence of activities that must be started and completed exactly as scheduled. It is the longest sequence of activities with zero float.

3. Why is the Critical Path Important?

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.

4. 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 22 activities over nine months. Let’s assume that there is another path of work that includes 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.

5. You must sequence activities to understand critical path

The critical path relies on an understanding of the successors and predecessors of each activity. If your activities are not sequenced, the critical path may be calculated erroneously. 

Four Techniques to Manage Your Schedule

You will never be a successful project manager if you do not know how to build and manage a schedule. The schedule may be the most fundamental tool for managing projects. Here are five techniques to help you take full advantage of the project schedule.  

1. The remainder of the schedule is the most important

The schedule should represent your best-guess at any particular point in time on how to complete the remaining work. The more complex your project is, the more change is going to be required in your “best guess” over time. The project manager must evaluate the schedule on an ongoing basis and determine the current state of the project. Based on the current state of the project, and your current understanding of the work remaining, you need to re-plot a course that will allow the work to be completed within the original budget and deadline.

2. Update the schedule weekly

For most projects, the schedule will need to be reviewed on a weekly basis. During this review, the project manager updates the schedule with the current state of work that is completed and in-progress. The remaining work should be evaluated to see if the project will be completed within the deadline. If it can, you are in good shape. If it cannot, the project manager must implement corrective action.

3. Proactively manage schedule variances

The project manager may be in a position of having to constantly utilize his experience and creativity to get the project completed within expectations. One week your project many be on track. The next week, you may have work assignments that are late and issues that have surfaced. If you are good at it, managing the schedule can be one of the more challenging and rewarding aspects of project management. If you do not relish the detailed work that is required, you may find it much more difficult to be successful as a project manager.

4. Validate who can update the schedule

On most projects the project manager is the only one that is allowed to update the schedule. However, there are other options, especially for larger projects. The project manager may ask each team member to update the schedule with actual hours worked, remaining hours and proposed end date. For very large projects, it is also common for one or more people to be assigned to update the schedule on behalf of the project manager. These people are sometimes called project administrators, project coordinators or project schedulers. They can get information from team members and update current status and actual hours worked. They bring this all to the project manager for final analysis and evaluation.

Apply These Three Techniques for Managing Scope

Freeze Scope Change Requests Late in the Project

The later scope changes occur, the more they tend to impact schedule and budget. You might think that as long as the sponsor is willing to approve increases in budget and time to make the change, they should be able to do it.

This is normally true - but only up to a point. There comes a time in a project where it just doesn’t make sense to make additional scope changes. That is the time to gain a commitment for a change freeze. Not only are new changes expensive to implement, they are a distraction to the project team.

Depending on the nature of the project, this freeze is usually implemented as the team is getting ready for the “drive to implementation”. At this point, the team is focused on implementing the solution. At that point in the project, scope change requests are not only costly, but they are also very disruptive. The team can lose focus and become mentally deflated. You may find that the next time there is a “drive to implementation” the team will get sloppy and make mistakes, since this would be the second time they performed these implementation activities.

The better approach is to hold these changes on a backlog and deal with them as enhancement requests after the solution is implemented and stable.

Track Valid Change Requests that are not Approved During the Project 

It is possible that the sponsor may not approve scope change requests during the project, but they may be viable requests that can be done at a later time. These types of change requests should be captured on a backlog list. After the project is completed and the solution is moved to the operations and support organization, there may be opportunities for enhancements or a Phase II project.

Do Not Use Estimating Contingency for Scope Changes

One of the steps in the estimating process is to add contingency hours, budget and schedule to reflect the level of uncertainty associated with the estimate. (For instance, if the effort hours were estimated at 5,000 hours, you might add 500 hours for contingency, which reflects a 90% confidence factor and 10% uncertainty.) Once the contingency is approved, there will be pressure on the project manager to use the contingency to absorb additional requirements. The client might say, “Why do we need to invoke scope change management for this 100 hour enhancement. You have 500 hours of contingency built into your estimate!”

The project manager must resist the temptation and the pressure. The purpose of the estimating contingency is to reflect uncertainty in the estimates. There will be plenty of opportunities to utilize the contingency when activities take longer than expected. Do not use the estimating contingency to absorb extra work.