Project Management

Create Detail and Summary Activities

If you look at a WBS activity and determine that it needs to be broken down to another level, the original activity becomes known as a “summary” level. A summary activity does not have any work or hours specifically associated with it. It represents a logical roll-up of the activities that are under it.

On the other hand “detailed” activities are those that have not been broken down further

Summary activities are broken down into detailed activities. Therefore once the detailed activities are under the summary activity are completed, the summary activity is also considered to be completed. If there is more work required, then additional detailed activities must be added under the summary.

Use the Post-It Note Approach for Collaboratively Creating the WBS

It might surprise you to know the number of people that use Post-it pads and a blank wall to create the first draft of the Work Breakdown Structure. This technique is very easy. You first get the appropriate people into the same room. These are the project team members and clients who have the expertise to build the WBS. Typically you start off by writing the names of the major deliverables on Post-it notes - one deliverable per note. Make sure the attendees agree on the major deliverables to begin with. If any of the deliverables are very large, you can create new Post-it notes that describe the deliverables at a lower level, or individual work products. These are arranged under the higher-level deliverable. The deliverable needs to be identified at a level low enough that you understand what it takes to build it. In general two levels should be enough. One level is typical.

Next, for each deliverable, describe the activities that must take place to complete it. Each activity goes on a separate Post-it note. These activities are arranged under the specific deliverable they refer to. If you have a sense for the order that the activities need to be completed, you can arrange the Post-it notes sequentially. However, this is not important at this point. The important thing is to identify all the work.

Look at the activities that are required to build each deliverable (or work product) and estimate the work associated with each activity. If the effort associated with an activity is larger than your estimating threshold, identify the more detailed activities that make up the higher-level one. Each of these activities is represented by new Post-it notes under the higher-level activity (which now becomes a summary activity). Continue with this process until the work required to complete all of the deliverables is defined, as best you know today. The levels of activities will not be the same for each deliverable. Some simple deliverables may meet the threshold criteria in one or two levels. Others may take three or four, or more levels.

The advantage of using Post-it notes is that your team can visually see the work and they can help ensure all the work is identified to complete the project. The Post-it sheets also give you the ability to easily move things around. If you add an activity and then decide to remove it, you just pick up the Post-it sheet. Likewise, if a deliverable or group of activities is in the wrong place, you just move the Post-it notes to where they need to be.

When you are all done, you can enter the detailed work activities into your scheduling tool. (The summary activities can optionally be considered as milestones since reaching the summary activity would signify all of the underlying detailed work is completed.)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Wideman Glossary Term of the Week - Build
(Click here for the fantastic Wideman Comparative Glossary - www.maxwideman.com/pmglossary/intro.htm)

• Put parts together to form a unified whole, construct.

• An operational version of a system or part of a system that demonstrates a subset of the capabilities to be provided in the final product.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Defining scope is perhaps the most important part of the upfront definition and planning process. If you don’t know for sure 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.

The purpose of defining scope is to clearly describe and gain agreement on the logical boundaries of your project. Scope statements are used to define what is within the boundaries of the project and what is outside those boundaries. The more aspects of scope you can identify, the better off your project will be. The following types of information can be helpful in defining scope.

• The deliverables that are in scope and out of scope. You should definitely include deliverables in your scope statements. However, only describe your final deliverables and the project deliverable that are client-focused. For instance, the Business Requirements Report and Current State Assessment could be listed as project deliverables since they are both client-approved deliverables. You would not need to mention internal project documents such as the project workplan, Technical Design or Test Cases.
• The major lifecycle 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.
• The types of data that are in scope and out of scope. Data types refer to financial data, sales data, employee data, etc. It is possible that your project works with some types of data and does not work with others.
• The data sources (or databases) that are in scope and out of scope. This is similar to the data types, except now you are referring to aggregated data, such as Customer Database, General Ledger, Billing / Invoicing System, etc. (These data sources may have more than one data type.)
• 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 focus on Human Resources and Accounting, but the Manufacturing Division might be out of scope.
• The major functionality that is in scope and out of scope. For instance, decision support and management reporting might be in scope, while overnight batch processing might be out of scope.

Use High-Level Objectives as Your Starting Point

When the project was proposed for funding, there should have been an initial set of high-level objectives and deliverables defined. Any information that was created earlier should be used as the starting point for defining the more detailed scope statements for the Project Charter. If you find that you do not have enough information to create a clear and comprehensive scope statement, you must work with the sponsor to gather additional information. That is one of the main purposes of the definition and planning process.

If you have project objectives, look at them to help shape the scope statements. By definition, there needs to be one or more deliverables created to fulfill each objective, and defining the project deliverables is one of the primary aspects of project scope. After you determine the major deliverables the project will produce, start asking other questions to determine other aspects of scope. The deliverables describe ‘what’ the project will deliver. You can also identify ‘what’ organizations are impacted, ‘what’ types of data are needed, ‘what’ major features and functions are needed, etc.

As a point of clarity and contrast, you can also identify out-of-scope conditions by describing what deliverables will not be created, what organizations will not be impacted, what features and functions are not included, etc. Of course, there are an infinite number of out-of-scope statements. For the purposes of scope definition, you want to include only those statements that help define the project boundary and touch upon related areas that the reader may have questions about. For instance, if you were installing financial software, you might state that a new Accounts Payable package is in scope, but the related Purchasing System is out of scope. This would make sense because the Purchasing and Accounts Payable processes are related and there may be questions as to whether the Purchasing System was in scope. However, you would not have to list every other system as out of scope – just the ones that the reader might have questions about.

It is a good practice to document those organizations that are in scope and those related organizations that are out of scope. The readers can then determine more easily if they are impacted or expected to assist in the project. Also, it may make sense to identify the organizations that are in scope so that you can have people from those organizations represented on the project team - perhaps on a steering committee.

Aligning Objectives and Scope

When you have completed creating your objectives and scope statements, go back and make sure that they are all in alignment. You should not have any objectives that make references to deliverables that are not defined in your scope statements. Likewise, you don’t want to include deliverables in your project scope that do not help to achieve the project objectives. If the two areas are not in full agreement, either the scope or the objectives (or both) must be modified to bring everything into alignment.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Weekly Anagram

Let’s have some fun! See if you can unravel this anagram. (Anagrams are a word or phrase formed by reordering the letters of another word or phrase, such as satin to stain.)

Consideration, inter-relationship and action of outside changes such as legal, social, economic, political or technological which may directly or indirectly influence specific project actions.

CAVEMEN INTRO NORM: _ _ _ _ _ | _ _ _ _ _ _ _ _ _ _ _

Last Week’s Anagram.

Written Approval

MEND SENT ORE: ENDORSEMENT

Wideman Glossary Term of the Week - Dependency

• A relation between activities, such that one requires input from the other.
• See Logical Relationship.
• The next task or group of tasks cannot begin until preceding work has been completed, thus the word “dependent” or “dependency”.
• A relationship between two modeling elements, in which a change to one modeling element (the independent element) will affect the other modeling element (the dependent element).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Project and Project Management Documents

The document repository holds all the project deliverables - both project-related and project management-related. For instance, the repository will hold the Project Charter and project schedule (project management deliverables), as well as the Technical Design and Testing Plan (project deliverables). When you start to consider your document management process, all of the documents your project produces must be taken into account.

Document Workareas

Usually the document repository does not hold documents that are currently being worked on (this may also depend on any document management software being used). Each team member should have a workarea where he or she can store versions of documents that are currently in-progress but not yet in circulation. This can be a directory structure or a folder that each team member has full access to. Team members can structure their work area in whatever way makes sense to them.

Draft Copies

Draft copies are documents that have been initially completed by the author, but are not yet ready to be considered entirely complete from a project perspective. In most cases, this is because the document is in some kind of review process. Draft copies of documents could be stored in the author’s workarea. However, for large projects, or ones where more rigor in document management is needed, it will make sense to maintain a library or folder for draft copies. In this case, the update process would look as follows:

1. A document is created and edited in the author’s workarea.
2. After the initial draft is completed, the document is moved from the workarea to the draft library. The document stays there until the author needs to update it or it is ready to be moved to the repository as an approved document.
3. When the document is in the draft library, it can be circulated for review and input.
4. If the draft copy needs to be updated again, the document is copied back to the workarea for updating, leaving a copy in the draft library.
5. This process is repeated until the document is totally complete. Then the document can be moved from the draft library to its final location in the document repository.

The value in this approach is that the project team always has one official draft of each document and only one live, approved version as well.

Garbage in – Garbage Out

This classic problem still exists in document management no matter how sophisticated your processes become. Document management helps you store and retrieve information that already exists in the project. However, even if you find the document, the content may or may not be helpful. Team members need to understand that their documents must be well-written so that others can read them and understand the content. On some projects, team members search for documents, find them, but then discover that the content in them is unusable. Your document management processes may help in these situations by getting others, including the librarian, involved in reviewing documents before they are added to the repository. However if you allow poorly-written documents to be added to the repository, you may find that people are not going to utilize the repository as often since they will not perceive value in the documents that the repository contains.

Document Management Technology Will Influence Your Process

Much of the process for managing documents is influenced by any document management technology used on the project. For instance, document management software will usually come with a standard logical structure. You just plug in your specific names to make it real. Software may also enforce versioning and have features for controlling update authority. The tool may also describe the metadata needed for keywords and indexing.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Weekly Anagram

Let’s have some fun! See if you can unravel this anagram. (Anagrams are a word or phrase formed by reordering the letters of another word or phrase, such as satin to stain.)

An overview or introduction to a topic.

RATIO TOE INN: _ _ _ _ _ _ _ _ _ _ _

Last Week’s Anagram.

A point in the project life cycle, usually separating major Phases or Stages, at which senior management has the opportunity to confirm or deny continuation into the next Phase or Stage.

CATTLEMAN ONE MORNING OPT: MANAGEMENT CONTROL POINT

Wideman Glossary Term of the Week - Mission

• A concise statement of a program or project’s overall purpose and reason for existence. See also Vision.
• A stretching, guiding and reinforcing statement of intent and commitment.
• The objective or task, together with the purpose, which clearly indicates the action to be taken.

  Editor’s Note: Usually expressed at a high or overview level to provide overall direction.

• Derived from the project vision, an action plan that is feasible in time and place and compatible with the pursuit of the vision.

Small projects do not need to be managed with the rigor and structure of a large project. However, they do need to have some processes in place. Schedule management is an area that should be considered. If your project is 50 hours, then the schedule is trivial and you do not need a formal process to manage the schedule. However, if your small project is a couple hundred (or a couple thousand) hours, then you need to have a more rigorous schedule and you need a “small” process to manage the schedule.

1. Review the schedule on a weekly basis.
2. Identify activities that have been completed during the previous week and update the schedule to show they are finished.
3. Determine whether there are any other activities that should be completed, but are not. If an activity is behind schedule, work with the individuals that are assigned to see what is going on. There could be problems that need to be resolved or it may be that the length of time needed to complete the activity was underestimated. Determine how much additional effort and duration are needed to complete the work and update the schedule accordingly.
4. Evaluate the remaining work to see if the project will be completed within the original effort, cost and duration. You may find that even though some activities may be completing later than planned, other activities may be completing early.
5. Adjust the schedule so that it reflects the remaining work to be completed. The first priority should be to complete the project within the original estimates for effort, duration and cost. If you are behind schedule or trending overbudget there are many techniques you can utilize to get back on track.
6. If the original budget or deadline estimates cannot be met, new estimates need to be prepared and communicated to management and the sponsor. The project manager must then negotiate a new schedule and budget. It is possible, for instance, that the sponsor is not able to approve an extension in the deadline, which may force the team to work overtime. This scenario may also require the clients to compromise on features to be able to get the work done on time. If the original budget or deadline is modified because the team cannot meet the original estimates, it is vital that the new numbers are realistic and that the team meets the new expectations.

Since this is the process for a small project, it would be unusual to have major problems on schedule or budget. If the budget or deadline needs to be extended once, the team absolutely needs to meet the new expectations.

When the work is done, make sure that you include activities in your schedule for the formal closure of the project. The project manager should not consider the entire project completed until these project closure activities are completed. You should use the same discipline to close the project as you did to manage the project.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Weekly Anagram

Let’s have some fun! See if you can unravel this anagram. (Anagrams are a word or phrase formed by reordering the letters of another word or phrase, such as satin to stain.)

Client-approved variation to a contract, bill of quantities, requirement specification or similar.

ADORER VAIN TRIO: _ _ _ _ _ _ _ _ _ | _ _ _ _ _

Last Week’s Anagram.

The class of tasks ancillary to analysis, design, and programming that are required to accomplish a software development effort; includes documentation (technical publications), quality assurance, test and integration, and the data center operations.

CREPE VISORS PUTS: SUPPORT SERVICES

Wideman Glossary Term of the Week - Reliability

• The ability of an item to perform a required function under stated conditions for a stated period of time.
• The probability that an item will perform its intended function for a specified interval under stated conditions.
• A fundamental characteristic of an item or material expressed as the probability that it will perform its intended function for a specified time under stated conditions.

Procurement refers to the aspects of project management related to obtaining goods and services from outside companies. This specifically refers to vendors and suppliers. It does not refer to other internal organizations within your own company. (For the purposes of this discussion, purchasing and procurement are equivalent terms.) This is an area that project managers definitely need to understand at some level, and it is an area into which the project manager will give input. However, in many, and perhaps most companies, procurement is an area that the project manager does not own. The project manager normally does not have the authority to enter into contracts on behalf of the company, and he normally is not asked to administer the contracts once they are in place.

If you are purchasing goods or services on your project, you should determine your project procurement strategy and plans. In some cases, you will simply follow the procurement contracts and plans that are already established by your company or your organization. For instance, you may purchase hardware from companies using a standard company contract. You may acquire contractors using your company’s preferred vendor list under prior master contractor agreements. In some cases, you will need to work with your Procurement Department to establish your own project-level vendor management plans.

The vendor identification and selection process can occur at different times. Many project teams consider the vendor identification and selection processes to be part of the actual execution of the project. In other words, they are done in the initial Analysis Phase after the project execution has started. This would be the case if you need to better understand your business requirements before you determine the vendor that can best meet the requirements.

In some cases, the identification and selection processes are executed outside of the project. In these cases the vendors and third-party products are all known before the project officially starts. This would be the case for vendors that are chosen on the basis of strategic priorities, and not based on the specific requirements of an individual project. For instance, your company may decide to purchase a leading customer relationship management (CRM) system based on high level business goals and strategies. This CRM system would then be used on all sales and marketing projects - regardless of the specific needs of each individual project.

Create Procurement Management Plan

The Procurement Management Plan describes how items will be procured during the project and the approach you will use to managing vendors on the project. Specific areas to describe include:

• Procurement process. This section provides a brief overview of the process requirements necessary to manage procurement of the identified needs. This process should include:
  • Initiating a request
  • Development of requirements (technical, timing, quality, constraints)
  • Request approval
  • Purchasing authority
  • Bid / proposal review
  • Contract management responsibility
  • Contract closure requirements
  • Procurement process flowchart
• Roles and responsibilities. This section describes the various roles on the project that have some connection to procurement. This section should describe who can request outside resources, who can approve the requests, any secondary approvers, etc.
• Identified procurement needs. This section details the material, products or services identified for outside procurement. Each listed item should include a justification statement explaining why this should be an outside purchase if there is the possibility of inside sourcing (make vs. buy decision).
• Timing. This section will describe the timeframe that resources are needed. This will provide a better sense for when the procurement process needs to be started for each item.
• Vendor processes. Describe the processes that the vendors should use for timesheet approval, invoice processing, contract renegotiation, status reporting, scope change requests, etc.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Weekly Anagram

Let’s have some fun! See if you can unravel this anagram. (Anagrams are a word or phrase formed by reordering the letters of another word or phrase, such as satin to stain.)

Those non-critical activities, i.e. with some float, that tend to group together to form subprojects within the project network.

DECAF HEN RISE: _ _ _ _ _ _ | _ _ _ _ _ _

Last Week’s Anagram.

Client-approved variation to a contract, bill of quantities, requirement specification or similar.

ADORER VAIN TRIO: VARIATION ORDER

Wideman Glossary Term of the Week - Team

• A group of people with a high degree of interdependence geared toward the achievement of a goal or the completion of a task.
• Two or more people working interdependently toward a common goal and a shared reward.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Outsourcing of project work is more common today than ever. However, even though you outsource the work, you cannot completely outsource your obligation to make sure the project is progressing smoothly. If all goes well with the outsourcer, you do not have much work to do. Unfortunately, in many instances, the outsourcing vendor does not perform against expectations. If that happens, you want to know about it as soon as possible. For the purposes of this discussion, let us assume that your company has outsourced a project, or a portion of a project. Your company has also asked you to manage the relationship to ensure the vendor performs as expected.

Many people are not sure what they should be doing when they are asked to manage an outsourcing relationship. Part of the uncertainty is because some of the project roles are reversed when you outsource work to a third-party. On a normal internal project, the project manager assigns the work and manages issues, scope, risk, quality, etc. The project manager makes sure work is done on time and the project is progressing as it should. He is held accountable for the success of the project. Other people perform a quality assurance role to make sure things are progressing as they should.

With an outsourced project, the vendor takes on the direct management of the outsourced work. The client project manager is now the one that has to ask the quality assurance questions to make sure the vendor project is progressing as it should. Some of the up-front questions to ask include:

• Is there a contractual agreement that spells out the expectations of both parties in terms of deliverables to be produced, deadlines, payment schedule, completeness and correctness criteria, etc?
• Has a comprehensive project schedule been created?
• What is the Project Management Plan the vendor will use to control the project?
• Has the vendor been clear on what resources will be needed from your company and when they will be needed?
• Have a number of agreed-upon milestones been established to review progress so far and validate that the project is on-track for completion?

Ongoing Questions

As the project is progressing, you must continue to ask questions to determine the current state of the work. You may have status meetings weekly, but there should be a formal quality assurance check at the end of every agreed-upon milestone. The types of questions you would ask at every milestone include:

• Have the deliverables specified in the Project Charter been completed up to this point?
• Have the appropriate deliverables been agreed to and approved by the company?
• If the vendor has met expectations up to this point, have any interim payments been released?
• Can the vendor clearly explain where the project is vs. where it should be at this time?
• Will all the future deliverables specified in the Project Charter be completed?
• Are issues, scope, and risks being managed as stated in the Project Management Plan?
• Should the contract or Project Charter be updated to reflect any major changes to the project?

Once you understand your role on the project, it is easier to ask the right questions to make sure that everything is progressing as it should.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Weekly Anagram

Let’s have some fun! See if you can unravel this anagram. (Anagrams are a word or phrase formed by reordering the letters of another word or phrase, such as satin to stain.)

The likelihood of a mistake.

LIBRARY ROBOT RIPE: _ _ _ _ _ | _ _ _ _ _ _ _ _ _ _ _

Last Week’s Anagram.

Those non-critical activities, i.e. with some float, that tend to group together to form subprojects within the project network.

DECAF HEN RISE: FEEDER CHAINS

Wideman Glossary Term of the Week - Budget Estimate

• See Estimate and Appropriation Estimate
• (Accuracy -10 to +25 %) An estimate prepared from flow sheets, layouts and equipment details. This is often required for the owner’s budget system. These estimates are established on quantitative information, are a mixture of firm and unit prices for labor, material and equipment. These estimates establish the funds required and are used for obtaining approval for the project. Other terms used to identify a Budget Estimate include Appropriation, Control, Design, etc.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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 deliverables, etc. It would have to be a fairly large mistake to be classified as a formal issue, but large mistakes happen all the time.

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. 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 probably 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. You have the personally-painful part out of the way. Now 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.

Provide Leadership to Implement Critical Change Requests

Change is not inherently bad or good. However, the team can react to changes in positive and negative ways, depending on the state of the project. A typical reaction from most project teams is to just go ahead and make the changes. However, there is another reaction that can be more problematic: the team may not want to make any more changes. This situation usually occurs on projects that have had problems and could be for a variety of reasons.

• This may be a long project, perhaps requiring overtime, and people just want the project to end.

• The proposed changes will require a lot of work, and the deadline date is being held firm. Again, overtime may be required from the team.

• Members of the project team and the client have not had a smooth relationship on the project. There may be project team members that do not want to help the client further.

• The changes require major upstream rework to the design, which will require changes to construction and re-testing of the entire solution.

All of these situations (and more) result in a scenario where the project team is not motivated to support scope changes. This puts the project manager in a tough position where he has to get the rest of the team on board for one last charge.

Frankly, it’s a tough sell. The team is tired and they are not motivated. In fact, morale may be poor. However, this is the time for the project manager to show leadership. Since the cause of the team problems is probably complex, the solution should be multi-faceted as well. Here are some things for the project manager to consider.

• Explain the facts first. Do not start with a rah-rah speech right away. First meet with the team and explain the background and circumstances. Then talk through the changes that are needed and why they are important from a business perspective.

• Acknowledge the pain. The project manager must acknowledge the problems. Let the team members know that you understand that they may not want to make the changes and that their morale is poor. Don’t dwell on it – but acknowledge it.

• Be motivational. Now is the time to motivate the team. Appeal to their sense of working together as a team to get through this adversity. Let them know the value they are providing to the company.

• Talk to everyone one-on-one. In addition to the team meeting, talk to the entire team one-on-one to understand where they are at mentally. Listen to their concerns and get their personal commitment to work hard and keep going.

• Get management and the sponsor involved. Now is also a good time to ask your manager and your sponsor to talk to the team, thank them for their work so far and ask for their continued help getting through the changes.

• Look for perks. Little perks can help a team get through motivational and morale trouble. These can be as simple as donuts in the morning and pizza for those that have to work late overtime.

• Make sure the clients are in there with you. Normally if the project team is working extra, the clients are sharing the pain as well. However, the project manager should make sure they are.

• Communicate proactively. Keep everyone informed as to the state of the project and the time and effort remaining. If the project manager starts getting closed and secretive with information, it causes many more problems to morale.

• Celebrate successes. The project manager does not need to wait until the project is over to declare success. Look for milestones, or mini-milestones, as opportunities to celebrate a victory and give praise to team members.

A project manager needs to have more management and leadership skills than simply telling people to “do their jobs.” This is a tough situation and requires good people management skills to get through successfully. Success is never guaranteed, but utilizing some of these tips can help you get through a tough situation.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Weekly Anagram

Let’s have some fun! See if you can unravel this anagram. (Anagrams are a word or phrase formed by reordering the letters of another word or phrase, such as satin to stain.)

A record of jobs to do or to check that others have done, commitments from the author or others, important events, decisions and discussion, and kept by the project manager and any team members.

ALLOY DIG: _ _ _ _ _ | _ _ _

Last Week’s Anagram.

The likelihood of a mistake.

LIBRARY ROBOT RIPE: ERROR PROBABILITY

Wideman Glossary Term of the Week - Discounted Cash Flow

• A calculation of present value of a projected cash flow based on some assumed rate of inflation or interest.

• A method for comparing the relative merits of project investments taking into account the value of money, taxation, varying operating costs, earlier cash returns for reinvestment etc. Also known as Internal Rate of Return. Although theoretically not as sound as Net Present Value, it is easier to present and relate to interest rates on borrowed money. Neither DCF nor NPV takes into account project risks.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -