Online Project Management

Training and Coaching

2009-09-18T10:18:00.000+08:00

Building Project Management Skills through Training and Coaching

Once the methodology has been selected, the PMO has to work to get the organization to adopt the common processes. Two of the primary ways this is done are through training and coaching services.

Training is one of the premiere services offered by PMOs. In fact, in many organizations, the primary role of the PMO is to offer project management training to the staff. Coaching refers to working with individual project managers or project teams to transfer knowledge and teach new skills. This is usually done in-person, but can also occur over the phone or through emails.

Determine your training needs and how to resolve them

Like many of the services offered, training must be considered holistically, along with any other services that the PMO is offering. It doesn't make sense to just start teaching classes. Project management is a very broad field. There are dozens of classes that can be offered, in many different formats and delivery modes. The PMO must take a step back first to determine the subjects that make the most sense to teach each audience, as well as the timeframe and dependencies of the subjects. The following steps will help.

Determine the scope of training. An early and fundamental decision to make is the scope of your training effort. One basic assumption is that if you offer project management training, the project managers will be the primary focus. However, there are other stakeholders as well. You need to decide what, if anything, you will target to project managers, team members, functional managers, clients and external partners. You must also decide on content scope. For instance, will you just teach methodology skills, or will you teach classes in soft skills as well (such as listening, leadership, etc.)?
Determine the training needs. The PMO should assess the skill levels of the organization within the overall scope that was determined earlier. This may have been done in an earlier organization assessment. If not, then you need to gather feedback from managers, clients and team members to find out strengths and areas for improvement.
Create your Training Strategy and Plan. Now that you have determined what you need, you need to determine how you will do it. The Training Strategy describes how you will implement training at a high level. The Training Plan describes the details behind the strategy. It gets down to the detailed level of determining the specific classes to offer, the order of the classes, how the classes will be developed and how they will be delivered.

There are many options to consider for training. For instance, customized classes can be developed and taught by the PMO. This option is especially valuable if the class must be delivered to many people and the cost of sending everyone to outside public courses is prohibitive. You also have the option of using consultants to help build the training classes much more quickly. You can look at distance learning options such as webinars to reach your remote staff economically. You can also look at computer-based training. In fact, there are many options to consider when developing the entire training curriculum. Once you have approval on these documents, you are ready to execute the plan.

Develop and teach the training curriculum. This is basically the execution of your Training Plan. You would buy, build or outsource various portions of your training needs based on costs, priorities and capabilities.

Coaching is more personal and targeted

Coaching is different from training. Training implies a formal teacher-pupil relationship, and the formal instruction of material. Coaching is less structured, and usually involves talking through situations and describing or demonstrating how project management techniques can assist. (Note that in some organizations, this type of service might be called project management consulting, or mentoring.)

If your PMO provides coaching services, you will need to be clear about what these services include. It is difficult for every Coach to have expert knowledge in all aspects of project management, especially when the deployment project is new. Instead, the coaching services should be aligned to the areas being deployed at that given time. For instance, if your PMO is initially deploying definition and planning skills to the organization, the coaching services should be on those same topics. The Coaches must be experts in those areas. On the other hand, if a project manager wants coaching on quality management, the Coach may have more limited knowledge. Later, when the PMO focuses on deploying quality management, all the Coaches should be knowledgeable in the subject.

You must also be clear on whether you will provide coaching in non-project management processes. For instance, if you are coaching on project management, you may get a request to help create a Test Plan. If the scope of your PMO includes project management only, this is a request you would not be able to help with. However, if your PMO also performs coaching on the development life cycle, then perhaps you would be able to help. Likewise, your PMO might receive a request to help a project team use a scheduling tool. Again, if this were not a part of the coaching service you are offering, you would need to decline the request.

Summary

The PMO needs ways to deliver the knowledge regarding the new project management processes to the organization. Formal training is one way to transfer this knowledge to many people at once. Coaching (or consulting) is a way to follow up the general training with personal service to reinforce what has been learned so far. This one-two punch is very effective at giving people the information they need, and then helping them retain the information and apply the knowledge to their current projects.

Estimating Duration

2009-09-14T23:21:00.002+08:00

It is very common for project managers (and others) to be asked to estimate the duration of a project or a large piece of work. You cannot provide an estimate of duration unless you also have an estimate of the effort hours. Even if you provide an initial estimate in terms of duration, you need to at least mentally understand the effort involved.

Estimates for effort are normally given in terms of hours. For instance, you might estimate a piece of work to be 500 effort hours. However, how long will this 500 hour piece of work take to complete? Now it becomes a little trickier. If a resource was working on the activity full-time, it might take 13 weeks+. If two people were working full-time, it might take seven weeks. If a person was working on the activity for 50% of the time, it might take a six months or more.

Calculating duration estimates is not as easy as it might sound. If everyone worked eight hours per day, and was absolutely, 100% productive for all that time, you could easily calculate the duration by taking the number of effort hours, divide by the number of resources, divided by the number of hours they work per day. For instance, if an activity was estimated at 80 hours, and you have one person assigned, and they work eight hours per day, the duration would be 10 days (80 effort hours / 1 person / 8 hours per day). Likewise, if four people were assigned, the duration would be (80 / 4 / 8) = 2.5 days.

However, those perfect circumstances are not indicative of how work is actually performed. Therefore, you can convert effort hours to duration for resource-constrained activities using the following process.

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 over time. In other words, if an activity is scheduled to take 40 effort hours, it is unlikely that it can be completed in a calendar week, without overtime. Using a factor of 6.5 productive hours per day will help you take into account socializing, morning ramp-up time, walking to meetings, going to the bathroom etc.

Determine how many resources will be applied to each activity. 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. (At some point, adding resources will not make the activity complete any sooner, and in fact, may make it go longer.)

Factor in available workdays, holidays, vacations, training, etc. This time was not included in the productivity factor above, since this non-project time can be scheduled and accounted for in advance. For instance, on a three-month project, each team member may be out for two holidays, while one may also have ten days of vacation.

Take into account any resources that are not full time. If you have a resource 50% of the time, it will take them 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 available for 25% of their time, the resulting duration will be at least four weeks - probably more.

Factor in multi-tasking productivity loss for part-time resources. You can do this if you have a sense for any additional assignments team members will be working on. (If you do not have this detailed information, you cannot easily factor in multi-tasking productivity loss, although you may be able to deduct a generic average.) If one person is working on multiple projects, or perhaps a combination of projects and support, a further reduction in productivity needs to be taken into account. This reflects the fact that if a person is shared on two or more unrelated efforts, it takes time to stop one and start up another. If a person is on two projects for 20 hours each week, they are going to lose additional productive time switching back and forth. If the person is on two projects, this might result in a 10% loss of productivity on both projects. If they are on three (or more) each effort could take up to a 20% productivity hit. For example, if a person was split between three projects for 24, 10 and 6 hours, the project managers should initially factor in closer to 20, 8 and 4 hours of productive time per week. Further, since there are three projects involved and there will be stopping and starting time, the re-factored productive time might be closer to 19, 7 and 3 hours respectively per project.

Calculate delays and lag-times. Some activities have a small number of effort hours, but a long duration. For instance, if you will be waiting for vendor supplied resources. You may be spending very little effort hours, but you need to wait until the vendor is ready. Another example is the duration required to get a deliverable approved. You may estimate the effort at only a few hours, yet it may take a number of days or weeks to gain the actual approval.

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

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 specialized international agency that promotes the development of precise standards to help ensure that products, services, and materials throughout the member nations remain consistent.

REALIZATION TANNING ORATION ADORNS DRAFTS: _ _ _ _ _ _ _ _ _ _ _ _ _ | _ _ _ _ _ _ _ _ _ _ _ _ | _ _ _ | _ _ _ _ _ _ _ _ _

Last Week's Anagram. The sequence of activities that must be completed on schedule for the entire project to be completed on schedule

CATTAIL CHIRP - CRITICAL PATH

Wideman Glossary Term of the Week - Budget Element

Budget elements are the same as resources i.e. the people, materials, or other entities needed to do the work. Budget elements can be validated against a Resource Breakdown Structure (RBS). They are typically assigned to a work package, but can also be defined at the cost account level.
The resources i.e. the people, materials, or other entities needed to do the work of the program. For example, engineer, technician, travel, and pipe can all be budget elements. These budget elements can be validated against a Resource Breakdown Structure (RBS). Budget elements are typically assigned to a work package, but can also be defined at the cost account level.

Create Detail and Summary Activities

2009-04-11T02:16:00.000+08:00

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

2008-04-13T01:36:00.000+08:00

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

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

Manage Documents on Projects

2008-04-11T01:27:00.000+08:00

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:

A document is created and edited in the author's workarea.

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.

When the document is in the draft library, it can be circulated for review and input.

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.

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.

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

Manage the Schedule and Budget - Small Projects

2008-04-09T01:16:00.000+08:00

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.

Review the schedule on a weekly basis.

Identify activities that have been completed during the previous week and update the schedule to show they are finished.

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.

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.

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.

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

2008-04-07T01:03:00.000+08:00

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.

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

Managing Outsourced Projects

2008-04-07T00:57:00.000+08:00

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.

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

Procurement

2008-04-05T10:33:00.000+08:00

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.

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

Openly Address Issues that You Cause

2008-04-05T00:38:00.000+08:00

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.

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.

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.

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.

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.

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

Projects vs. Products

2008-04-02T17:34:00.000+08:00

Projects vs. Products

Projects are the way that most new work gets delivered. All projects have certain characteristics in common.

They all have a beginning and an end.
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 also have assigned resources - either full-time, part-time or both.

There are other characteristics as well.

Projects can be managed using a common set of project management processes. In fact, a similar set of project management processes can be utilized regardless of the type of project. For instance, all projects should be defined and planned, and all projects should have processes to manage scope, risk, quality, status, etc.

Products on the other hand, are tangible items that are produced by a project, or perhaps purchased from a vendor. (The vendor would have created the initial product through a project.) Project management can be thought of as a process. A product is delivered by a project. “Product management” is an approach for centrally coordinating the activities surrounding the long-term support and enhancement of a product. The person that executes these responsibilities is called a Product Manager.

The product management process can start during the project that created the product. If you purchased the product, the product management process can begin when the product is purchased, or a little earlier in the product evaluation and selection process.

Product Management

The role of a project manager is to plan and manage a project. The role of a product manager is focused on the long-term support of the product within the organization. The product management role includes the following responsibilities.

Product Planning
- Coordinate product issues and all communication as the primary contact with the product vendor
- Monitor product direction with the vendor and communicate this information to company stakeholders
- Determine which components of the product should be used in the organization
- Identify opportunities for use of the product
Testing
- Coordinate testing of new products and releases, including coordinating pilots with potential product users
- Determine when a product is “production-ready” based on testing and pilot projects
- Coordinate certification of new products and releases
Financial Management
- Coordinate negotiation of product contracts, purchase agreements, and maintenance agreements
- Ensure that budget is available for product purchases and maintenance
- Determine when to consider canceling or reducing maintenance payments based on product direction
Product Implementation and Deployment
- Coordinate development of a product deployment plan
- Manage and monitor the deployment of the product or new releases
- Deploy (distribute) the product
- Track product inventory (where the product has been deployed)
- Receive ongoing requests from the staff for individual product deployment
- Integrate and add new products and releases into the architecture
Product Release Management
- Decide when to upgrade to a new release
- Plan and manage new release implementation
- Ensure new releases get added into the architecture if required
Product Retirement
- Determine when product needs to be retired
- Plan and manage product retirement
- Retire (uninstall) the product from the environment
- Ensure product gets removed from the architecture

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 original plan (for a project, a work package, or an activity), plus or minus approved changes

LABS APE LINEN: _ _ _ _ _ _ _ _ | _ _ _ _

Last Week's Anagram.

The total expenditure for acquiring an asset. The sum of all moneys spent on a project and transferred to the capital account of an organization, usually upon completion

COAL ACT TIPS CAPITAL COST

Wideman Glossary Term of the Week - Key Event Schedule

A schedule comprised of key events or milestones. These events are generally critical accomplishments planned at time intervals throughout the project and used as a basis to monitor overall project performance. The format may be either network or bar chart and may contain minimal detail at a highly summarized level. This is often referred to as a milestone schedule.