SENAD AGOVIĆ

Top 10 Qualities of a Project Manager

2011-09-23T12:55:00.000+02:00

What qualities are most important for a project leader to be effective? Over the past few years, the people at ESI International, world leaders in Project Management Training, have looked in to what makes an effective project leader. With the unique opportunity to ask some of the most talented project leaders in the world on their Project Leadership courses ESI have managed to collect a running tally on their responses. Below are the top 10 in rank order according to frequency listed.

Inspires a Shared Vision

An effective project leader is often described as having a vision of where to go and the ability to articulate it. Visionaries thrive on change and being able to draw new boundaries. It was once said that a leader is someone who "lifts us up, gives us a reason for being and gives the vision and spirit to change." Visionary leaders enable people to feel they have a real stake in the project. They empower people to experience the vision on their own. According to Bennis "They offer people opportunities to create their own vision, to explore what the vision will mean to their jobs and lives, and to envision their future as part of the vision for the organisation." (Bennis, 1997)

Good Communicator

The ability to communicate with people at all levels is almost always named as the second most important skill by project managers and team members. Project leadership calls for clear communication about goals, responsibility, performance, expectations and feedback.There is a great deal of value placed on openness and directness. The project leader is also the team's link to the larger organisation. The leader must have the ability to effectively negotiate and use persuasion when necessary to ensure the success of the team and project. Through effective communication, project leaders support individual and team achievements by creating explicit guidelines for accomplishing results and for the career advancement of team members.

Integrity

One of the most important things a project leader must remember is that his or her actions, and not words, set the modus operandi for the team. Good leadership demands commitment to, and demonstration of, ethical practices. Creating standards for ethical behaviour for oneself and living by these standards, as well as rewarding those who exemplify these practices, are responsibilities of project leaders. Leadership motivated by self-interest does not serve the well being of the team. Leadership based on integrity represents nothing less than a set of values others share, behaviour consistent with values and dedication to honesty with self and team members. In other words the leader "walks the talk" and in the process earns trust.

Enthusiasm

Plain and simple, we don't like leaders who are negative - they bring us down. We want leaders with enthusiasm, with a bounce in their step, with a can-do attitude. We want to believe that we are part of an invigorating journey - we want to feel alive. We tend to follow people with a can-do attitude, not those who give us 200 reasons why something can't be done. Enthusiastic leaders are committed to their goals and express this commitment through optimism. Leadership emerges as someone expresses such confident commitment to a project that others want to share his or her optimistic expectations. Enthusiasm is contagious and effective leaders know it.

Empathy

What is the difference between empathy and sympathy? Although the words are similar, they are, in fact, mutually exclusive. According to Norman Paul, in sympathy the subject is principally absorbed in his or her own feelings as they are projected into the object and has little concern for the reality and validity of the object's special experience. Empathy, on the other hand, presupposes the existence of the object as a separate individual, entitled to his or her own feelings, ideas and emotional history (Paul, 1970). As one student so eloquently put it, "It's nice when a project leader acknowledges that we all have a life outside of work."

Competence

Simply put, to enlist in another's cause, we must believe that that person knows what he or she is doing. Leadership competence does not however necessarily refer to the project leader's technical abilities in the core technology of the business. As project management continues to be recognised as a field in and of itself, project leaders will be chosen based on their ability to successfully lead others rather than on technical expertise, as in the past. Having a winning track record is the surest way to be considered competent. Expertise in leadership skills is another dimension in competence. The ability to challenge, inspire, enable, model and encourage must be demonstrated if leaders are to be seen as capable and competent.

Ability to Delegate Tasks

Trust is an essential element in the relationship of a project leader and his or her team. You demonstrate your trust in others through your actions - how much you check and control their work, how much you delegate and how much you allow people to participate. Individuals who are unable to trust other people often fail as leaders and forever remain little more that micro-managers, or end up doing all of the work themselves. As one project management student put it, "A good leader is a little lazy." An interesting perspective!

Cool Under Pressure

In a perfect world, projects would be delivered on time, under budget and with no major problems or obstacles to overcome. But we don't live in a perfect world - projects have problems. A leader with a hardy attitude will take these problems in stride. When leaders encounter a stressful event, they consider it interesting, they feel they can influence the outcome and they see it as an opportunity. "Out of the uncertainty and chaos of change, leaders rise up and articulate a new image of the future that pulls the project together." (Bennis 1997) And remember - never let them see you sweat.

Team-Building Skills

A team builder can best be defined as a strong person who provides the substance that holds the team together in common purpose toward the right objective. In order for a team to progress from a group of strangers to a single cohesive unit, the leader must understand the process and dynamics required for this transformation. He or she must also know the appropriate leadership style to use during each stage of team development. The leader must also have an understanding of the different team players styles and how to capitalise on each at the proper time, for the problem at hand.

Problem Solving Skills

Although an effective leader is said to share problem-solving responsibilities with the team, we expect our project leaders to have excellent problem-solving skills themselves. They have a "fresh, creative response to here-and-now opportunities," and not much concern with how others have performed them. (Kouzes 1987)

References

Bennis, W., 1997. "Learning to Lead," Addison-Wesley, MA.
Kouzes, J. M: "The Leadership Challenge," Jossey-Bass Publishers, CA.
Norman: Parental Empathy. Parenthood, Little, Brown, NY.

Source: http://www.projectsmart.co.uk/

Project Start and End-dates

2011-06-17T14:27:00.002+02:00

One of the characteristics of a project is that there is a definite start and end-date. This seems simple enough until you start to try to define exactly what these dates mean. There are no universally recommended standards for either date. In many respects, it depends on each organization and whether there are any implications for choosing one alternative over another. Here are some of the options for identifying the project start-date.

The idea is generated.
This takes the start-date back a long way before the project is actually formalized and on the surface this definition may not make sense. However, remember that the definition you choose can depend on what the implication is. You may choose this definition if your company is trying to focus on the time it takes between when an idea is generated until the idea is fulfilled though a project. The concern may be that there is too much time to implement good ideas. If your company wants to minimize this total time span between idea and fulfillment, you might go with an early project start-date definition like this.
A budget is approved.
This definition is a little more concrete than the prior idea. In this definition, an idea has been generated and the idea has made it far enough that a cost/benefit statement has been prepared. The project has also made it through the prioritization process and an actual budget has been approved. Keep in mind that the budget may have been approved during the prior year business planning process. The actual work may not start until the following year. Therefore, this definition may also start the clock too early for many organizations.
A project manager is assigned.
This one is more common. It may be hard to say that a project has started before a project manager is assigned. When the project manager is assigned, the project planning and definition begin and the meat of the project starts. This is the general definition for project start-date that is utilized in the TenStep process.
The Project Charter is approved by the sponsor.
In some organizations the project officially starts when the client approves the Project Charter document. Some companies require an approved Project Charter and schedule before the project team can be allocated. They do this to ensure that the up-front agreement is in place before project work begins.
The project kickoff meeting is held.
Using this definition, the planning and definition work is considered to be “pre-project” work. All projects start with a formal kickoff meeting with the client and project team. By the time the kickoff meeting is held, the planning is completed, the client has approved starting the work and the project team has been allocated. The kickoff meeting is the time to tell everyone that the project is ready to begin. Because of this prior work, most organizations consider the kickoff meeting to be too late to use as the definition for the project start-date.

Why the Start-date is Important

To a certain extent, you might think that it doesn’t really matter when the project starts. Having a somewhat undefined start-date does not take away from the fact that the work is a project. It’s obvious that the project started at some point, since there was a point when the work was not in progress and a point where the work was in progress. So, at some point the project did in fact “start”.

The reason it is important to know the start-date is that there may be consequences and incentives based on how long it takes to complete a project. The following are examples of these consequences.

Project team accountability.
It is hard to hold people accountable for things that are not within their control. For that reason, it makes sense that a project manager is held accountable for the project no earlier than when he is assigned. If the project clock starts before he is assigned it is possible that some decisions were made and some resources expended beforehand, and therefore he does not have total control. Likewise, if team members are held accountable for completing a project within budget and on schedule, it is hard to hold them accountable for work and decisions that take place before they are assigned. For that reason, perhaps the project should officially start when the project manager is assigned, while team members are accountable for what happens after the Project Charter and schedule are approved, or after the project kickoff meeting is held.
Process improvement.
Many companies keep track of the total duration of projects and attempt to shorten the average project duration over time. It is important that everyone within the company use a common starting and ending point. Otherwise the project duration statistics will not be meaningful.
Financial / accounting.
Many projects have capital expenditures from an accounting standpoint (versus expense accounting). Precisely defining when a project starts has consequences in terms of the work that can be capitalized and the work that needs to be expensed.
Comparisons with other companies.
If you compare how long it takes your organization to deliver projects versus other organizations or other companies, you want to make sure you have a common definition of start and end-dates. If your company considers a project to start when a project manager is assigned and other companies start the clock at the kickoff meeting, it will appear that your company takes longer to deliver projects.

The question of when a project formally starts and ends is one that most people take for granted. However, there is not an easy answer for every organization. There are probably one or two answers that make most sense from a project management standpoint, but there may be cultural or financial factors that cause your organization to define the project boundaries differently.

Use One of Five Strategies for the Risk Response

2011-05-04T23:14:00.002+02:00

You should create a risk response for all “high” risks. There are a number of options that the project manager should consider for responses.

Leave it.
In this approach, the project manager looks at a high risk and decides to do nothing. This can happen for one of two reasons. First, the project manager may feel that the risk should be managed, but that the cost and effort of managing the risk is more than the impact of the risk event itself. In this case you would rather deal with the costs of the risk occurring that the cost of trying to manage the risk. The risk event has some probability of occurrence, which means that it is possible the event will not happen anyway.

Second, there may not be any reasonable and practical activities available to manage the risk.
This is different from the prior reason where the cost was more than the benefit. In this case, there is no practical way to manage the risk, even if the risk has been identified as high. For instance, it is possible that there is a risk of your sponsor leaving and a new sponsor canceling the project. However, you may not be in a position to do much about it as long as the current sponsor is in place, and you may just need to leave it and see how events play out.

Monitor the risk.
In this case, the project manager does not proactively manage the risk, but monitors it to see whether it is more or less likely to occur as time goes on. If it looks more likely to occur later in the project, the team must formulate a different response at a later time. This is a good approach if you have identified a risk that should be managed, but the risk event is far off in the future. For instance, if your risk event is nine months in the future, it may not make sense to spend resources to manage the risk at this time. A better approach might be to monitor the risk on a monthly basis. It is possible that over time the risk will go away because of other circumstances. However, if it does not go away, the team will still need to manage the risk in the coming months.

Avoid the risk.
Avoiding the risk means that the condition that is causing the problem is eliminated. For example, if you find that a part of the project has high risk associated with it, that whole part of the project can be eliminated. The risks associated with a particular vendor, for instance, might be avoided if another vendor is used instead. This is a very effective way to eliminate risks but obviously can be used only in certain unique circumstances. In another example, you may have a project risk associated with implementing a solution in multiple locations. Once the risk is identified, the sponsor may change the scope of the project to only implement in one location. In this way, the risk of implementing at multiple locations has been avoided.

Move the risk.
In some instances, the responsibility for managing a risk can be removed from the project by assigning the risk to another entity or third party. For instance, you may identify a risk associated with a new technology. Outsourcing the function to a third party might eliminate that risk for the project team. The risk event is still there, but now some other entity is dealing with it. The third party might have particular expertise that allows them to do the work without the risk. Even if the risk is still present, it now is up to another party to resolve.

Mitigate the risk.
In most cases, this is the approach to take. Mitigating the risk means that you put in place a set of proactive steps to minimize the likelihood that the risk will occur. If possible you could eliminate the risk by minimizing the likelihood down to zero percent. Another purpose of mitigation is to ensure that if the risk occurs, the negative impact of the risk is minimized. In many cases it may not be possible to totally eliminate a risk event, but given that you have time to prepare, you should be able to minimize the probability of the event occurring, or minimize the impact to the project if the risk event does occur.

These are typical risk responses for negative risks.

Think of Positive Risk as a Way Gain Benefit

Risk is usually associated with potential events that have a negative impact on the project. However, there is also a concept of opportunity risk or positive risk. In these instances, the project manager or project team may introduce risk to try to gain a benefit. For instance, a team may decide to utilize a new technology on its project because they think it will result in dramatic effort and cost savings. Of course, there is also a chance the new technology will not work. However, the team introduces the risk because the potential for gain. This is an example of intelligent risk taking or positive risk.

How to Show the Value of Project Management Training

2011-04-13T21:50:00.001+02:00

Many businesses struggle with the question of whether they are getting their money’s worth in sending employees to training seminars. This question can be applied to project management training as well as any other type of business training. You know the cost side of training too well. But how do you tell what the business value is?

What We Ask Today

The most common way to determine business value today is to ask the trainee whether he or she thinks the class was valuable. This is very touchy-feely and doesn’t give you much information to go on, but it is probably the most that most companies ask in terms of follow-up. Another method is to see how much of the class content that can be applied on the job. But again, this is usually done informally, without an attempt to actually see how the performance of the trainee improves.

A Rigorous Approach

There is a process for more rigorously determining the value received for your training dollars. These ideas are not for the faint of heart. They take more preparation and they take more of that most precious commodity – time. But see if it makes sense, and whether the results of this process will give you a much better feel for the value that you are receiving from training. You can also start with some of these steps, and try for the rest later.

First, the trainee and their manager meet a few weeks before the training is scheduled to make sure the trainee is ready for the class. The manager and trainee discuss how the training can help the trainee on their job. One of the important parts of the discussion is to identify opportunities where the trainee can apply the new skills on their job. This information should be documented so that it can be compared with a post-class assessment done later.
When the actual class begins each of the trainees should complete an initial survey showing their specific knowledge level of the class material.
Immediately after the class, each trainee completes a survey showing how they liked the class, instructor skill level, how the logistics were, etc. These surveys are designed for the benefit of the training company and the instructor. The survey provides a sense for how the class went and how the instructor performed. This survey is not designed to show how much you learned at the class.
A week or two after the class, the trainee completes a post-class survey showing their current knowledge level in the subject. For the most part, it is exactly the same as the initial survey from activity #2 above. This is compared to the initial survey to provide some sense as to how much the trainee learned - at least in their own opinion. If this survey comes out close to the original version, it may show that the training may not have been very effective. You would expect that the post-class survey would show improvement.
Here is the key step. A few months after the class, the trainee and their manager meet again for a post-class assessment, which is a follow-up to activity #1 above. In this discussion, the trainee and manager discuss the value of the class, and whether the class resulted in increased productivity and increased business value. Part of this discussion focuses on the opportunities that the trainee has had to apply the new skills. In fact, the training may have been superb, but if there have been no opportunities to apply the new skills, then the business value will be marginal.

Summary

In most training classes today, the trainee completes the class feedback for the benefit of the training company, and then tells his or her manager how good the class was. This superficial feedback is all that is available to gauge business value. However, the real test of business value is whether the class resulted in an increased skill level that can be applied to the job to make a person more productive. This cannot be determined immediately after a class. However, you can get a sense for the business value in two steps. First is a knowledge survey completed a few weeks after the class, and compared with an initial baseline. However, the only way to determine business value is to determine in the months after the class whether or not the training has actually been applied to your job. If you capture this information on all your classes, you will get a much better and more fact-based view of whether the classes you pay for are providing business value to your company.

Techniques to Create a Work Breakdown Structure (WBS)

2011-04-07T22:29:00.000+02:00

There are two types of WBS's - a deliverable-based WBS and an activity-based WBS. The deliverable-based WBS goes down to the deliverable or work package level. The activity-based WBS contains the activates needed to create the deliverables.

When the team is creating the activity-based WBS, there are usually questions about how small the detailed work activities should be. The answer determines when to stop breaking the work down into smaller activities. Part of the answer is to utilize an overall estimating threshold. This threshold is a maximum size (in effort hours) that an activity should be. Once you are under that threshold you can stop breaking the work down further. For instance, if your threshold is 80 hours, you can stop breaking down the work further once you have activities that are less then 80 hours.

Other things to take into account include:

The activity should contain sub-activities that are related and continuous. For instance, if you had an activity called 'Create Testing and Training Strategy', it probably should be broken down further, since the Testing Strategy and Training Strategy are not necessarily related and they are not necessarily continuous.

The activity should be able to be completed by one person, or one group of related people. If you have an activity that requires different people for different sub-activities, then it should be further broken down into the sub-activities so that a person or the same group of people can complete the entire activity. Remember that the detailed activities ultimately are carried over to the schedule. You don’t want to have one schedule activity that is assigned to two different groups, or two unrelated people.

In general, the work should be broken down to a level that makes sense for the project manager to control. Theoretically, the schedule could be broken down to a point where each activity was one or two hours. Obviously, it does not make sense to break the work down to this level. The assigned team member will not need the work described at that level of detail and the project manager does not need to manage the work at that level.

Other techniques are described below.

Do Not Make the WBS Too Tall

If you envision the WBS being built with Post-it notes on the wall, it is important that you not let the WBS get too tall (or too deep). Depending on your WBS approach, it may take you one to three levels to get the deliverables defined. The general rule of thumb is that the number of levels for each deliverable should not exceed five and even five might be too many. Smaller projects may not need more than two or three levels of activities for each deliverable. If you have a very large project, the levels might be deeper. However, there is a point where the detail will be too complex to manage. If you find that you are defining down to five or more levels of activities for a deliverable, stop and evaluate what you are doing. First, you may be defining the work at too low a level. Second, you may have defined your deliverable too broadly. In that case, see if a large deliverable can be broken up into smaller, integrated pieces. The work associated with the smaller deliverables should not require so many levels.

Break Large Projects into Phases and Stages
There are differing terms used to describe the ways that large projects can be divided and subdivided. A couple of the common terms are phases and stages. There may not be universally recognized definitions for these terms, but in general they mean the following.

Stage: This is the easier term. This is usually always used to signify an internal breakdown of work on one project. For instance, you might refer to the gathering of business requirements, and all related work, as the Analysis Stage. Similarly, if your project requires the building of a prototype, you might call this the Prototype Stage.

Phase: Phases can have two meanings. First, in many cases, the word 'phase' means exactly what was just described as a ‘stage’. For instance, a project may have a Requirements Phase or a Prototype Phase. In that context, phase refers to a high-level breakdown of internal work. If the term 'stage' is also used, it refers to a further subdivision of a phase. For instance, in the Analysis Phase, there may be a Business Requirements Stage and a Strategy Definition Stage.

The second use of the term “phase” refers to a series of independent but related projects. For instance, the original execution of a project to deliver basic functionality might be referred to as Phase I. A subsequent project to add more functionality might be called Phase II. A rollout of the package might be Phase III. In all these cases, the term 'phase' is used to imply a separate project, but one that is related to similar projects in a series that come before it and after it.

The names of the term is not as important as the concept to group related chunks of work together.

Create a Work Breakdown Structure Dictionary for Large Projects

Normally a dictionary would not be needed, but if your WBS has hundreds (or thousands) of detailed activities, there may just be too much to keep track of by hand. If the WBS is very large, it might make sense to place all of the important information in a data dictionary. The dictionary helps keep track of all of the summary and detailed activities, including a short description, the WBS numeric identifier (1.1, 1.1.1, 1.1.2, etc.) and the estimated effort. Once the WBS information is entered into a tool, the tool can also help to keep track of changes to the work so that you can trace how the change impacts the WBS and the schedule. Having the WBS in a tool also makes the information easier to reuse for future projects.

Use Your Summary Activities for Schedule Milestones

Your WBS contains both detail and summary activities. When you create the network diagram in your schedule, however, you should only include the detailed activities, not the summary ones. For the sake of clarity and readability, it often makes sense to include these higher-level summary activities in the schedule as well to represent a logical roll-up of the detailed activities. A summary activity that represents the completion of a major deliverable could also be included in the schedule as a milestone.

The 5 Goals of a Project Manager

2011-03-31T15:17:00.001+02:00

As a Project Manager, you need to manage people, money, suppliers, equipment - the list is never ending. The trick is to be focused. Set yourself 5 personal goals to achieve. If you can meet these simple goals for each project, then you will achieve total success. So read on, to learn...

The 5 Goals of a Project Manager

These goals are generic to all industries and all types of projects. Regardless of your level of experience in project management, set these 5 goals for every project you manage.

Goal 1: To finish on time

This is the oldest but trickiest goal in the book. It's the most difficult because the requirements often change during the project and the schedule was probably optimistic in the first place.

To succeed, you need to manage your scope very carefully. Implement a change control process so that any changes to the scope are properly managed.

Always keep your plan up to date, recording actual vs. planned progress. Identify any deviations from plan and fix them quickly.

Goal 2: To finish under budget

To make sure that your project costs don't spiral, you need to set a project budget at the start to compare against. Include in this budget, all of the types of project costs that will accrue, whether they are to do with people, equipment, suppliers or materials. Then work out how much each task in your plan is going to cost to complete and track any deviations from this plan.

Make sure that if you over-spend on some tasks, that you under-spend on others. In this way, you can control your spend and deliver under budget.

Goal 3: To meet the requirements

The goal here is to meet the requirements that were set for the project at the start. Whether the requirements were to install a new IT system, build a bridge or implement new processes, your project needs to produce solutions which meet these requirements 100%.

The trick here is to make sure that you have a detailed enough set of requirements at the beginning. If they are ambiguous in any way, then what was initially seen as a small piece of work could become huge, taking up valuable time and resources to complete.

Goal 4: To keep customers happy

You could finish your project on time, under budget and have met 100% of the requirements—but still have unhappy customers. This is usually because their expectations have changed since the project started and have not been properly managed.

To ensure that your project sponsor, customer and other stakeholders are happy at the end of your project, you need to manage their expectations carefully. Make sure you always keep them properly informed of progress. "Keep it real" by giving them a crystal clear view of progress to date. Let them voice their concerns or ideas regularly. Tell them upfront when you can't deliver on time, or when a change needs to be made. Openness and honesty are always the best tools for setting customer expectations.

Goal 5: To ensure a happy team

If you can do all of this with a happy team, then you'll be more than willing to do it all again for the next project. And that's how your staff will feel also. Staff satisfaction is critical to your project's success.

So keep your team happy by rewarding and recognizing them for their successes. Assign them work that complements their strengths and conduct team building exercises to boost morale. With a happy motivated team, you can achieve anything!

And there you have it. The 5 goals you need to set yourself for every project.

Communication Management Plan Examples

2011-03-31T13:54:00.001+02:00

There are three types of communication - mandatory, informational and marketing. When you create a Communication Plan for your project it might make sense to have different types of communication that fit into all three categories.

Mandatory

These types of communication are required by your company, your industry or by law.

Project Status Reports
Regular voicemail updates (of status)
Status meetings
Meetings with steering committee
Regular conference calls and videoconferences with remote stakeholders
Required reports to shareholders or your Board of Directors
Government required reports and other information
Required financial reporting such as budget vs. actuals, budget variances, etc.

This information is “pushed” (sent directly to) to recipients.

Informational

This is information people want to know or that they may need for their jobs. You put this information in a place that people can access and you tell them that it is there.

Awareness building sessions that people are invited to attend (these are not meant as training – just to build awareness of the project)
Project deliverables placed in a common repository, directory, website or library that people can access
Frequently-asked questions

This information is made available for people to read, but requires them to take the initiative, or “pull” the communication.

Marketing

These are designed to build buy-in and enthusiasm for the project and the deliverables. This communication is especially important if your project is going to change how people do their jobs. These types of projects are culture change initiatives.

Project newsletters with positive marketing spin
Meeting one-on-one with key stakeholders on an ongoing basis
Traveling road shows to various locations and departments to explain the project and benefits
Testimonials from others that describe how the project deliverables provided value
Contests with simple prizes to build excitement
Project acronyms and slogans to portray a positive images of the project
Project countdown-until-live date
Informal (but purposeful) walking around to initiate discussions about all the good things the project is accomplishing
Celebrations to bring visibility to the completion of major milestones
Project memorabilia with project name or image portrayed, such as pins, pencils, Frisbees, cups, T-shirts, etc.
Publicizing accomplishments

This type of communication is “pushed” to the readers.

The point of the examples is to show that project communication can take many shapes and forms. For large projects especially, the project team should be creative in determining how, what, to whom, where and how frequently the communication takes place. If the project is controversial, requires culture change or is political, the positive aspects of marketing communication become more and more critical.

Defining Scope

2011-03-10T21:53:00.004+01:00

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

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. There are two major aspects of defining scope on your project – deliverables and boundaries.

The deliverables
Even if you are not sure what else to include in your scope definition, you should always include your deliverables. Understanding the deliverables you are producing goes a long way to understanding the scope of the project. There are many deliverables that could be listed, but you should focus on the final deliverables of the project, plus any internal deliverables that are client-focused.
Project boundaries
Boundary statements are used to describe aspects of the environment that are in-scope for the project versus those that are out of scope. You would not need to state that some aspect of the project was in-scope unless you could also contrast that with some aspect that is out of scope. The nature of a true boundary statement is that there is both an in-scope and a relevant out-of-scope counterpart. For example.
- The major life-cycle processes that are in scope and out of scope.
  For instance, your project may include the Analysis Phase only and not the Design, Construct or Test Phases.
- The types of data that are in scope and out of scope.
  “Data types” refer to business units such as 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 organizations that are in scope and out of scope.
  In some cases, the organizations involved in the project help to define the boundaries. For instance, your project may be applicable to the Human Resources and Accounting Departments, but the Manufacturing Division might be out of scope.
- 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.

These two areas - deliverables and boundaries are used to define the high-level scope of the project.

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. There may even be some type of high-level scope statement. 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. These statements help shape the boundaries.

As a point of clarity and contrast, you can also identify out-of-scope conditions. 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. If you are not building something to satisfy an objective, you will not be able successfully complete the objective.

Likewise, you don’t want to include deliverables in your project scope that do not help to achieve the project objectives. If you are proposing to build deliverables that do not help you achieve your project objectives, you would need to ask yourself why. Since the objectives describe the purpose of the project and are used to validate project success, why would you want to build deliverables that do not help you achieve your objectives?

If the objectives and the deliverables in your scope section are not aligned, you need to determine how to bring them into alignment.

If you have an objective without a deliverable, you need to validate whether the objective is really important. If it is, then you will need to add or modify the deliverables to satisfy the objective.

If you have a deliverable without an objective, then you need to ask whether the deliverable is really important. If it is not, then remove it from the project. If the deliverable really is important, you need to work with the sponsor to determine the business objective for creating it. It is likely this objective is valid, but unspoken yet.

Aligning objectives and deliverables will help ensure that you are building all of the deliverables required to support the objectives - and no more.

How to Manage Your Project Finances

2011-03-07T23:58:00.003+01:00

Step 1: Set the Budget

The first step towards managing your project finances is to set a budget. This isn't as easy as it sounds. You need to forecast the total amount of people, equipment, materials and other expenses, needed to deliver the project. You then need to work out when in the project plan, these expenses will take place. By doing this, you can get a picture of your "project cashflow" which tells you the amount of money you need for every week in the project.

Step 2: Backup Funding

Before you need it, find backup funding in the business. This is additional funding that can be used to deliver your project, if you need it. Few Project Managers actually do this in advance, but if you have almost completed a major deliverable and you suddenly run out of money, then that backup funding might "make or break" the project. You are always in a better position to get backup funding before you need it, rather than asking for more cash when you've already overspent. Get backup funding as early in the Project Life Cycle as possible. It will be sure to reduce your stress.

Step 3: Weekly Tracking

The next step after setting your budget and securing backup funding is to start tracking your daily spend on the project. You need to track every expense that occurs. Ask your team to complete expense forms and submit them to you for approval. If you can get your team to wait until you have approved an expense before it is incurred, then you can more easily control expenditure on the project. Next, you need to track your people expenses. This is easy in www.ProjectManager.com because every person is assigned an hourly rate. The total cost of the hours undertaken by those people is automatically shown on the Project Dashboard, so you can see whether your people cost is under or over budget.

Step 4: Realignment

When you start spending more than your budget, you have 3 options available to help you stay within budget:

Re-forecast your expenses and present a new budget to your Sponsor for approval.
Start reducing costs immediately. This means spending less to get the same job done. Or alternatively, see if your Sponsor will agree to a reduced scope, so that you have less to produce for them.
Start using your backup funding to get you through the crux of the project.

Step 5: Cashflow Management

Make sure you always have enough funds available to cover your spending over the months ahead. Cashflow management is about managing the cash needed to deliver your project. So make sure your Sponsor has approved the next 1-2 months of work ahead of time, and that the funds needed to manage the project have been made available. Then track the spending of that funding every week.

Use Monte Carlo Analysis for Sophisticated Scheduling

2011-03-07T23:51:00.003+01:00

Many classes and many books briefly mention Monte Carlo analysis (this is also called Monte Carlo simulation and Monte Carlo modeling). Many authors think the concept is important enough to note in passing, but not necessarily so important that they want to spend a lot of time explaining how it works.

Monte Carlo is a name given to a technique that is used to create a simulation, or a model, that describes how a process will likely turn out. The simulation does not return a single answer, but a range of possible answers, and the probability that each answer will occur. Although you may have heard the term in the context of project management, it is actually a general modeling technique that can be applied to any process where there is uncertainty involved in the process. Examples include nuclear processes, financial derivatives, physics experiments, etc. The term was coined during the Manhattan Project (building the atomic bomb) during World War II, but the general concepts have been known for hundreds of years. However, it has become more common now that computers can be used to simulate thousands, or millions, of trials. The common theme is that there must be a series of discrete tasks to simulate, and there must be uncertainty, or risk associated, with the tasks.

Applying to Project Management

While it would be fascinating to see how to apply Monte Carlo techniques to experiments in sub-atomic physics, the more practical use at hand is how to apply these techniques to project management. The techniques can be used to model the project cost, or they can be applied to certain project risks. The more common use is in the creation of the project schedule, and the determination of the project end date.

When you put together your project schedule, you typically create a series of tasks, and an estimated duration for each task. When you are done, you look at the resulting timeline to see the estimated end date. However, the chance of hitting that exact end date is not 100%. In fact, the chance of hitting that exact end date is probably pretty low. That is because you are never 100% certain of the duration of the underlying activities. Since we have process steps and uncertainty associated with each step, a Monte Carlo analysis can be performed.

A Simple Example

To use the Monte Carlo analysis, you can no longer just create one estimate of duration for an activity. You need to create three. First, estimate the most likely duration, and then estimate the worst case and the best case. Along with each estimate, include a probability that it will occur. (An even more sophisticated approach is to not just rely on three estimates for each task, but to use a distribution model that represents the probability of every possible outcome for the task. However, that is more than is necessary for this discussion.)

Let’s look at a small project with three tasks that must be worked on sequentially. Task A is likely to take 3 days (70%), but it is possible that it could take two days (10%) or four days (20%). Task B will likely take six days (60%), but could take as little as five days (20%) or as long as eight days (20%). Likewise Task C will probably take four days (80%), or as little as three days (5%) or five days (15%).

Okay, you might be able to see that this way of estimating takes longer, but it does tend to give you more precision. The question is, how long will this project take to complete? You can see that this question is now more problematic.

The Guts of Monte Carlo

The Monte Carlo analysis involves a series of random simulations on this three-step project. Each time, it plugs in random task durations for A, B and C based on the probabilities that we provided. It is possible that the first time through, it calculated twelve days (2 + 6 + 4). The next time it calculated eleven days (3 + 5 + 3). Then it calculated twelve days again (3 + 5 + 4).

Now, imagine that this simulation is run 1000 times. By the time the simulation completed, you would expect that there are around 700 simulations where task A took three days (70%). Likewise there should be around 150 simulations where task C took five days (15%). Each time a simulation is run, an end date is determined.

The Results

When the Monte Carlo analysis is complete, you do not have a single end date. Instead, you have a probability curve showing expected outcomes, and the probability of achieving each one. When you tell your stakeholders when the project will be completed, you would typically pick the duration that gives you a 90% chance of success. In other words, you would say that, based on the Monte Carlo simulation, you have a 90% chance of completion within X days, and then report the date that this falls on.

Summary

This example contained three tasks. Think about the projects that you have with hundreds, or thousands, of tasks. The Monte Carlo analysis allows you to show the uncertainty associated with the duration of these tasks. (You do not need to show uncertainty in every task – just the ones where you think the major uncertainty lies.) Many, but not all, project management scheduling packages allow you to perform these simulations. The software can run thousands of simulations on your workplan, and then give you information that will show the dates where you have a 50% chance of completion, 80% chance of completion, 90% chance of completion, etc.

Monte Carlo analysis is not something that typical project managers need. However, certain projects contain enough risk and uncertainty that it would make sense to use this technique. However, much more diligence is required for the detailed estimates. If you provide estimates and probabilities for the detailed activities that are not well thought out, the resulting simulations will be invalid as well, and you may end up with schedule completion dates that are not realistic.

Monte Carlo is an interesting topic, but I recommend that most project managers stick to the current best-guess estimating techniques. It would take a special project and special circumstances to utilize the rigor of Monte Carlo techniques.

Basics of Document Management

2011-02-25T11:05:00.000+01:00

The larger the project, the more rigor and structure is needed to manage documents. You can end up with a big mess trying to save and find documents if you do not think through a good document management plan ahead of time. The following areas should be considered part of an overall document management plan. These items do not reflect a process, per se, since many of the items can be considered and implemented in any order.

Determine where to store documents
The project team should have a common area, or repository, for storing documents. This could be in a file directory, document management software package, paper file cabinet, etc. The project manager should be sure that documents are not stored in multiple locations based on the preference of each team member. If that happens, the team will have difficulty finding important documents when they are needed – especially if there is turnover among members of the team.
Determine the types of documents to include.
The team also needs to determine the types of documents that will be added to the document repository. It is possible that the repository can hold every document in every stage of completion, including drafts and documents in each team member’s work area. However, it is also common for each team member to have a work area for his own documents and for the document repository to only hold final, approved deliverables.
Define a logical and physical document organizational structure.
Once you know where you will store documents, you should also determine the directory or folder structure. This will provide guidance to team members on the specific locations to store documents and will likewise help the team find documents when they are needed. The first step is to define a logical view of how the documents should be organized. The logical view just means that you place a draft on paper for feedback. Once you have agreement on this view, you need to implement it in the specific directory structure or tool. The structure should be one that is easy to understand and easy to use to find relevant information. After you have created this logical view on a couple projects, you will start to see similarities and you may find it beneficial to create a standard logical organization structure for all projects.
Define naming standards.
It can be hard to find documents even if you have a good organizational structure. A common document naming standard will make it easier. An example was described previously for Status Reporting naming conventions. One convention could be '20061201 Joe Smith Status Report'. In this scheme, all the status reports for a given timeframe would sort together. On the other hand 'Joe Smith 20061201 Status Report' groups the reports by person. The project manager needs to make sure that everyone is using the same naming scheme. Although this exercise might seem tedious, having a common naming standard for related documents will be very valuable as your project team generates hundreds of documents over time.
Determine if some documents need versioning.
The project manager should determine whether multiple versions of documents will be saved or if just the latest version will be saved. Many documents, such as the Project Charter, should have all approved versions saved. For these documents, the naming convention will need some type of version number. For instance, the original document might be named 'ABC Project Charter ’ 1'. The document name would be changed to ‘ABC Project Charter v 2’ if it is revised at a later time. People can then still refer back to the prior versions if necessary. On the other hand, documents such as the Issue Log only have a current version, and historical information is saved within the document. The current Issues Log always replaces the prior Issues Log, and there is no reason to keep separate versions. If you have a document management system it probably provides a versioning feature for you.
Determine if (and how) you will track document approval status.
When documents need to be approved, and especially if the approval process can be lengthy, it is important to signify the document approval status. For instance, it is important to know whether a deliverable you are reading is a final approved version or a draft. Having separate libraries for documents as they go through the approval process can do this. Typical document indicators are “draft”, “work in-progress” and “final”. When a document is created, it is in “draft” mode. When the document is being circulated for approval, it is moved to the “work in-progress” folder. When the document is approved, it is moved to the “final” folder.
Define standard document formats.
It is easier in the long run to read and create documents if they all follow a standard format such as font style and font size. In addition, the team can create standard headers and footers, cover pages and table of contents. This will give all the documentation a standard look and feel.
Identify standard document tools (optional).
The team needs to have a standard set of document-processing tools. Normally this is not a problem if the team is all from the same area. However, the lack of common tools can be a problem if your project team includes people from different organizations, different countries or different companies. For instance, something as simple as a standard word processing tool is normally not a problem. However, if you have suppliers and vendors on your team, you may have some team members using MS Word as their word processing tool and some using WordPerfect. Similarly, all team members need to have the same spreadsheet software. Once the standard software is identified, you also need to ensure the entire team is on the same release. In other words, if you want to use MS Word on your project, make sure all team members have the same version of MS Word. Sometimes your documents will not be able to be easily shared if the creator and the reader are not on the same software release.

Think about document management ahead of time on large projects. It will save you a lot of extra work and aggravation one the project starts.

5 Tips on Project Reporting

2011-02-19T23:42:00.001+01:00

Project status
Create a weekly Project Status Report to show your actual vs. planned effort, percent complete and actual vs. forecast spend. Specify the number of open risks, changes and issues, and state whether action by your Sponsor is required to resolve them. Also show the forecast amount of time, effort and money required to finish the project. Always try and forecast as accurately as possible. Never forecast optimistically, always conservatively.
Task completion
You need to regularly show your Sponsor your progress against the tasks listed on your schedule. Create a summarized view of your project plan and update it to reflect the percent complete for every task. Then append this summary view to your Project Status Report. This way, your Sponsor can drill down to see further information about each task, if they want to.

By offering your Project Sponsor both summary and detailed information weekly makes them feel like your project is an "open book". They will have all of the information about your project at their finger-tips. This way, you will get more buy-in from your Sponsor and more support when it's needed.
Milestones
You need to add Milestones to your project plan to show when the major project deliverables will be produced. You then need to report on the progress of each milestone to your Sponsor. Show the percent complete of each milestone, and again, forecast the completion dates.

Here's another tip: You will get more out of your team if you motivate them to complete milestones, as opposed to tasks. That's because people are usually proud of the things that they have achieved in life (i.e. milestones), as opposed to the things they have done to achieve them (i.e. the tasks).
Getting help
Project Sponsors don't always want to hear "we're on track and under budget" in their project reports. They just want to hear the truth. So if you’re behind schedule and you need help to get back on track, then tell your Sponsor about it in your project reports.

State exactly what you need from them. Show them that you're doing the best you can and that you’re the best person for the job, but that you still need their help to deliver the project. If you need more time, money or resources, then ask for it. Don’t be afraid. And remember, the best time to ask for help is before you really need it. This gives you contingency, because it always takes time for help to arrive.
One version of the truth
Your project reports need to depict "one version of the truth" to your team. Keep them 100% accurate and be as open as possible about real issues that are affecting your team. Remember that if you communicate an issue to your Sponsor, then it becomes their issue to fix as well. Reporting issues is a great way to share the responsibility for fixing them.

Top 10 Qualities of a Project Manager

2011-02-12T20:08:00.001+01:00

Inspires a Shared Vision
Good Communicator
Integrity
Enthusiasm
Empathy
Competence
Ability to Delegate Tasks
Cool Under Pressure
Team-Building Skills
Problem Solving Skills

Estimating Effort

2011-02-12T20:03:00.002+01:00

The first part of estimating a project is to estimate the effort hours. You can use the following simple process.

1. Determine how accurate your estimate needs to be.

Typically, the more accurate the estimate, the more detail you need to understand about the project, and perhaps the more time that is needed. If you are asked for a rough order of magnitude (ROM) estimate (-25% - +75%), you might be able to complete the work quickly, at a high level, and with a minimum amount of detail. Perhaps you can provide a ROM estimate based on knowledge in your head. On the other hand, if you must provide an accurate estimate within 15%, you need to spend more time and understand the work at a lower level of detail.

2. Create the initial estimate of effort hours

For a top-down estimate you would try to estimate the work at the project level. For instance, if a similar project took 1000 hours, you could start estimating your project at 1000 hours.

For a bottom-up estimate you would estimate the work for each activity, or for each of the lower elements in the work breakdown structure, and then add up all the detailed estimates for an overall estimate. There are a number of techniques to use including analogy, expert opinion, parametric modeling and others.

3. (optional) Factor the effort hours based on the resources assigned

Your estimates are probably based on the effort it will take an average resource to do the work (or perhaps the estimates are based on the effort it would take if you did the work). Sometimes you also have knowledge of the exact resource or the type of resource that will be assigned. If you do, you may want to factor the estimate up or down. For instance, you may estimate an activity to take 40 effort hours. However, you also know that the person who will do the work is an inexperienced trainee. In this case, you may want to double the estimate to 80 hours. Another set of activities may be estimated to take 200 hours. However, you know that you will hire an experienced contractor to do the work, so you may be comfortable reducing the estimate to 150 hours. Obviously, this step can only be performed if you have some sense for the actual resources to be applied to the project.

4. Add specialist resource hours

Make sure you have included hours for part-time and specialty resources. This could include freelance people, training specialists, administrative help, etc. These are people that may not be obvious at first, but you may need them for special activities. Because they are typically in project support roles, you may have forgotten to include their activities in the original Work Breakdown Structure.

5. Add project management time

Project management takes effort and there is an associated cost as well. You need to allocate effort hours to successfully and proactively manage a project. You should add 15% of the effort hours for project management. For instance, if a project estimate is 12,000 hours (7 - 8 people), then a full-time project manager (1800 hours) is needed. If the project estimate is 1,000 hours, the project management time would be 150 hours. This would not be enough for a full-time project manager, so the project manager would either be a part-time project resource or the project manager would also have non-project management activities assigned to him as well.

6. Add contingency hours

Contingency is used to reflect the uncertainty or risk associated with the estimate. If you are asked to estimate work that is not well defined, you may add 50%, 75% or more to reflect the uncertainty. If the estimate was required on short notice, a large contingency may be required. Even if you have time to create a reasonably accurate estimate, your contingency may still be 10-25%. If you do not add a contingency amount, it would mean that you are 100% confident in your estimate. This may be the case if similar types of projects have been done before.

When you add contingency, the best approach is to include it as a separate line item. However, if your organization will not allow you to include a formal estimating contingency, you may have no choice but to include the estimating contingency by padding the estimates of all the underlying activities. This is not the preferred approach, but it is the natural reaction if your organization will not allow a formal estimating contingency budget to reflect estimating uncertainty.

7. Calculate the total effort

Add up the estimates for all the work components described above.

8. Review and adjust as necessary

Sometimes when you add up all the components, the estimate seems obviously high or low. If your estimate does not look right, go back and make adjustments to your estimating assumptions to better reflect reality. Also make sure that your estimating model is consistent and reasonable. For instance, if a repetitive activity is planned, you might initially calculate the total effort by multiplying the effort to complete one activity by the number of times the activity is executed. However, upon further evaluation, you may realize that the effort to complete the activity will decrease as it becomes routine. You should also make sure that similar activities have similar effort estimates and if they do not, adjust them as needed.

9. Document all assumptions

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

Managing Projects with Unrealistic Deadlines

2011-02-02T00:38:00.002+01:00

If you are a project manager dealing with what you perceive to be an unrealistic deadline, the first thing you will want to try is to discuss this with your manager and see if there are any factors that are driving the project deadline that you may not be aware of. Sometimes the person who tells you of the deadline seems like the bad person, but see if you can understand what the motivation is. For instance, there may be a business driver that is driving the deadline. There may be some event occurring that this project needs to support. Or your project may be one of a number of initiatives that need to come together at a specific time. It does not necessarily make your challenge any easier, but you may find that by better understanding the reason for the deadline, you may have an easier time getting yourself and your team members motivated to try to achieve it.

On the other hand, if the deadlines seem arbitrary and are not the result of some other business driver, then you should find that out as well. Sometimes managers set arbitrary end dates just to provide what they consider to be stretch objectives. However, this can end up like the story of the boy who cried wolf. If your manager is not careful, there will be a time when there is a firm business justification for an aggressive end date, but no one will believe it.

Once you understand the motivation for the deadline date, there are project management techniques that can be utilized to increase the chances of success and better manage expectations.

Try to Adjust the Triple Constraints of Time, Cost and Scope

All projects require time and budget to create the deliverables agreed to in the project scope. When one of these constraints is out of balance, at least one of the others needs to be adjusted to get them back in alignment. For instance, if your budget is cut, you need to reduce the scope or increase the time to deliver.

If you find that the time constraint is not in alignment with cost and scope, talk to your manager about increasing the resources that are available for the project. Adding resources to the project could make the cost go up, but may allow you to hit the deadline. Also talk to your client about reducing the project scope. See if there are features and functionality that they can live without for now so that you can deliver the project within the deadline specified.

Utilize Risk Management

When you start a project, the first thing you need to do is the planning process. One aspect of the planning process includes identifying risks and putting plans into place to manage the risk. In your case, if you don't think you can hit the imposed end-date, now is the time to say something. When you do, your manager and your client start to hear that the end-date is at risk before the project even begins. As part of the risk identification, you can ask the project team, your client and your manager for their ideas on how to mitigate the risk. Utilizing risk management will help better manage expectations early in the project and also be a way to gather input and ideas for ways that you might be able to hit the deadline.

Utilize Scope Management

On many projects, you start with an aggressive delivery date, and then the situation gets worse because the project manager does not effectively manage scope. Then you end up having even more work to do by the deadline date. Disciplined scope management will ensure that you only have to deliver what was originally promised, and that any approved changes are accompanied by a corresponding increase in budget and timeline.

Aggressively Manage the Workplan

In many projects, you might get a little behind but have confidence that you can make up the time later. However, when you start a project with the deadline at risk, be sure to manage the workplan diligently. You have no margin for error. If early due dates start to slip, you are going to be in trouble early. As you monitor the workplan, treat missed deadlines as issues and work hard to solve the reasons behind the slippage. Again, get your team, management and clients involved. If your clients are causing delays, get more accountability from your business managers for helping to resolve project resource problems. Again, if the problem cannot be resolved perfectly, at least you are continuing to manage expectations.

Look for Process Improvement Opportunities

Lastly, take an honest look at your workplan and your approach for executing the project. Talk to your team, clients, and manager about any ideas they may have for making the project go faster. This will get everyone thinking about being part of a solution. Document any suggestions you receive. Show your client the project plan as well. If you are not achieving the end date they expect, ask them for ideas on how to shorten the project. See if they can help you come up with a solution to the scheduling problem, instead of just passively waiting for the project to be completed.

In addition, perform a self-evaluation of the project workplan and see if there are ways that you can reduce costs and cycle-times. For instance, are there some different development techniques that you could try that might decrease the end-date? Could you utilize a Joint Application Development (JAD) session to gather requirements more quickly than traditional interviewing techniques? Look at how you currently deliver projects and how you manage them to see if there are ways that you can accomplish what you need for less time and cost.

Summary

In summary, although it appears that you are being held accountable for events and circumstances that are not within your control, you do have control over the processes you use to manage the project. First, see if you can balance the early deadline by increasing resources or reducing project scope. Second, proactively manage risk, scope and the workplan so that you can better manage expectations and have the best chance for success given the constraints you are under. Third, work with your manager, client and project team to evaluate how you are executing the project. You may discover ideas and techniques that will allow you to deliver the project sooner that you might have first thought possible.

The PMO Should Perform Audits and Assessments to Validate Progress

2011-01-12T15:37:00.000+01:00

Most PMOs spends quite a bit of time focused on deploying common project management practices in their organization and building project management skills in their staff. But is it working? The PMO can validate whether all of this work is effective through a combination of project auditing and organization assessments.

Project-Level Audits

Project audits serve two functions.

You audit to check compliance. It is used to ensure that project managers are using the new project management processes. The results of the project audits will be used as input into the periodic organization assessments.
Auditing can also be an opportunity for coaching. During the audit, you can help the project manager understand how the methodology is applicable to their project. If project managers are open-minded, a project audit could be an opportunity to learn new things about how the project management processes apply to them.

It is one thing to provide training and coaching and have all the appropriate processes and templates defined. It is another thing for the new processes to actually be adopted and utilized by the project teams. If you want to change the culture and make sure that the new processes are sticking, you must make sure that the project teams are utilizing them correctly. The purpose of the auditing session is to determine how well the project manager and project team are utilizing the project management methodology. During the project audit, a member of the PMO asks a series of questions to ensure compliance with the required processes and procedures..

Keep the Management Structure Responsible as Well

If your organization is set up with the project managers reporting directly into the PMO, then the adoption of project management processes is within the control of the PMO. However, in most organizations, the project managers continue to report into their functional organizations. In any culture change initiative, middle management plays a key role in overall success or failure. Middle managers can be a huge asset if they are behind the culture change. Unfortunately, they can also be the biggest obstacles to overcome if they are not totally on board. (Unfortunately, this is more typical of the general role that middle managers play.)

To help reinforce the responsibilities of the managers, the results of the project audit should be documented and sent back to the project manager, as well as the manager of the project manager. In addition, the results are summarized and sent to the PMO sponsor, Steering Committee and other management stakeholders. If a team is not using the standard processes, the senior managers and the PMO sponsor ultimately need to ask why. This is part of a governance process.

Don't Audit All Projects

The auditing process can be time-consuming. Just as it is not possible to provide coaching for all projects, it is also not practical to audit all projects. Actually, you don't need to. If you audit a project in a certain department and it comes out pretty well, it is likely that the other projects in that same area will also come out well, since the functional manager is probably helping with the push. On the other hand, if you audit a project and find the standard procedures are not being followed, it is likely a sign that the manager from that area is not being supportive of the methodology, and other projects in that area will probably have problems as well. Raising visibility of the problem projects should bring organizational pressure to make the proper changes.

Organizational Assessments

Audits are done on a project-by-project basis. However, on a periodic basis (yearly or semi-annually), the PMO should look at the entire organization and assess how well the project management processes are being integrated into the work routine. The assessments can consist of feedback from project audits, interviews with key managers and stakeholders, anecdotal feedback and any metrics that are available. These assessments are compared to the prior assessments to gain a sense for the progress being made. This information is especially interesting to the PMO sponsor and other management stakeholders who need to understand how the project management deployment is going and whether it is successful or not.

If you are implementing in a large organization, you will probably find that some areas are implementing the processes more effectively than others. For that reason, the assessment needs to be sure to cover all major departments or divisions.

By performing a number of assessments over time, the PMO can gain a sense of whether project management processes are being successfully integrated into the organization. Assessments also offer the opportunity to take corrective actions if the new processes are not being successfully integrated into the organization.

Summary

It would be nice if you could develop a common methodology, train everyone, and then sit back and let the magic happen. Unfortunately, this rarely happens in a culture change initiative. The PMO must look at this project management implementation in a holistic manner; including validating that things are progressing according to plan. On a project level, this verification includes ongoing project audits to validate that project teams are utilizing the new methodology as expected. On a wider basis, the PMO should conduct periodic organization assessments and compare the results against the original Current State Assessment. These comparisons will point out the overall progress (or lack of progress) that has been made up to that time.

Branding a Project

2011-01-08T08:07:00.002+01:00

There are three major categories of communication within a Communication Management Plan – mandatory, informational and marketing. Your project will probably always have mandatory communications and you will want to add information communication as well if the project is large enough. Marketing communication is where the creativity comes in. Many projects have no need for marketing communication. However, if your project is controversial or if it requires culture change to be successful, you should focus on marketing communications.

Branding is a more sophisticated form of marketing communication. The purpose of branding a project is to associate an emotion or a feeling with your project. This is exactly what marketing people try to do when they brand a product. For instance, The Coca-Cola Company hopes that you feel good about its products and that you will choose its products from a crowded store shelf because you like the image and emotion associated with it. Maybe it works. If you throw a party and you provide a cooler full of Cokes and Sprites, you probably feel pretty good about the image you are portraying. On the other hand, if you stock a cooler full of ‘no-name’ cola, you might feel a little embarrassed. If you do, the branding process has had an effect on you.

Branding a project has the same connotation. The purpose of branding a project is to associate a positive image and emotion when a person hears of your project. This is not something most projects need to be concerned about. However, ask yourself some questions regarding the impact your project will have on the organization.

Does it impact a large number of people or maybe the entire company?
Will it require a culture change or a change in the way people do their job?
Will your project make people nervous? For instance, will it result in efficiencies so that less people are required to do the same function?

These are the types of projects that would be candidates for branding.

All large projects have an emotion associated with them. If you don’t do anything, this emotion is generally negative. It is just the nature of people that they seem to think that changes are bad. Branding helps you proactively build the image you want to portray rather than getting stuck with one. Of course, branding takes time, so you also need to have a project with a long time horizon.

There are activities that a project can perform to help with the branding campaign. If possible, you should consider meeting with your marketing department to gather more ideas and get help with how to establish a brand and how to successfully implement it. Examples of activities include:

Establish a positive project name
For instance, a project called MarketForce, probably gives more of a positive image than one called Marketing Process Improvement Initiative. You can build a positive image with an easy to remember acronym as well.
Establish an image / logo
The project should have an image or logo associated with it. The image must be positive and it should be included on all communication coming from the team.
Distribute branded “trinkets”
Put your project name or logo on pins, t-shirts, pencils, Frisbees, etc. You can reward people with a token that contains the project logo when they do something good.
Hold face-to-face meetings
Spend the time to see as many people as possible in person-to-person meetings or small group meetings, especially at the beginning of the project. No one wants to hear all the information about an important project on email. It cheapens the project.

Of course all of this is contingent on also including a steady stream of informational content as well. A steady stream of information, combined with the positive feeling of the project branding will help the project be successful and should help overcome any negative perceptions about the project.

Why is Branding Important?

Branding a project has definite bottom-line value when it is time to implement your solution. If your project will change how people do their jobs, they may quickly turn negative toward your project. When people are negative, it is much harder to successfully implement your solution. On the other hand, if people have a positive feeling about your project (or at least neutral) it is much easier for you to implement your solution.

That is the value of branding. You recognize that you can influence how people perceive your project and you can make a conscious effort to establish a positive image. This will result in your project implementation being more successful, more quickly, than it will if people have a negative perceptions. The small effort you take to establish a positive brand will more than pay off with a more successful implementation.

Create a Short-Term Schedule to Guide the Definition and Planning Processes

2011-01-04T08:38:00.001+01:00

The process of creating the Project Charter, schedule and budget may take a long time and may be very complicated. Therefore, the work should not be left unorganized, for the same reasons that you are building the schedule for the project to begin with. Immediately after being assigned, the project manager should create a short-term schedule to plan and guide the initial activities. This initial schedule should cover the length of time needed to create the Project Charter and schedule. If this is a two-week process, the project manager should create an interim schedule of at least two weeks - probably three. If the time to create the final Project Charter and schedule is four weeks, this initial schedule should cover at least four, if not five or six weeks. This preliminary schedule covers all of the organizing and up-front planning activities until the formal project schedule is completed to guide the remainder of the project.

This up-front schedule should be defined at an organizational level so that all projects use the same schedule template to define and plan the work.

Determine if You Will Capture Actual Effort Hours

A very early decision needs to be made as to whether you will capture actual effort hours on the schedule. For instance, let’s say you estimated an activity to have 40 hours of effort and ten days duration. It is easy to know when the activity is complete so you can compare estimated duration against actual duration. However, are you going to keep track of whether the effort was actually 40 hours? Capturing actual effort hours requires much more diligence on behalf of the project team to keep track of their time per activity and report it back accurately. There is a lot of value associated with capturing actual effort hours, including helping make future estimates more accurate. However, many organizations do not capture the actual effort hours. If your organization does not capture actual effort hours, it will be difficult for a project manager to enforce this discipline on one specific project. Collecting actual effort hours is usually something that is required (or not required) on an organization-wide basis.

Be Cautious About Having too Much Slack in the Schedule

There is only one path through the schedule that does not have any slack or float. This is the critical path and it will drive the end-date. Although every other path in the schedule has some slack, there might be some concern if there is too much slack. “Too much slack” means that the other paths have many long gaps when no work needs to be done. This can lead to a long “skinny” network diagram. Of course there may not be a problem with this occurrence. However, the potential implication of having too much slack in the schedule is as follows:

Many resources are coming and going in and out of the project, and this can cause potential problems making sure everyone is available when needed and for as long as needed.
On a similar note, if you use the same resources off the critical path, you may have to mix in non-project work for them when they do not have project work to do. You may assign them a few weeks of project work, then find other work for them during the slack time, and then make sure they are available for you again when they have more project work assigned.
There may be a lack of urgency on the part of all resources that are not on the critical path. In other words, you have one or more resources working hard on critical path activities and end-dates, while everyone else has a lot of slack in his schedule. This can be de-motivating to the resources on the critical path.

Be Cautious About Having too Little Slack in the Schedule

Just as there is risk with having too much slack, there is also some risk associated with not having very much slack. If this happens, minor schedule slippages off the critical path could force these paths critical as well. It would be better if the project schedule could be built in such a way that the non-critical paths were “full but not too full” so that a group of resources could be utilized more efficiently on the project.

Deliver your Projects Faster

2011-01-03T23:13:00.003+01:00

Here are 5 tips for delivering projects faster...

Tip 1: Find Shortcuts in your Plan

Project Managers usually spend 80% of their timeexecuting and 20% planning. The reason is that the Execution phase is where the excitement is, so they roll their sleeves up and get started executing as quickly as possible.

But if you spend extra time in the Planning phase, then you can usually identify shortcuts which enable you to produce the same project outcome in less time.

So when you think your project plan is complete, take extra time to re-look at your plan from the point of view of delivering it faster. By doing this, you'll find that you can schedule things to be done in a way that takes less time, with less effort.

Tip 2: Automate Manual Tasks

You need to automate your manual daily tasks to help you do things faster. Here are some of the manual tasks that many Project Managers do each week that could be automated using project software:

Summarizing data for your Weekly Status Reports
Collating Timesheets and Expense Forms
Updating your Project Plan with timesheet data
Working out whether the project is on track
Reporting on risks, changes and issues.

You don't need to perform these tasks manually. You can invest in project software to do all this for you. Your team will enter the data you need and the software will group and summarize it all for you. All you need to do is run reports and view the current status of your plan to ensure it remains on track.

Tips 3: Manage Execution Carefully

When your project gets underway, manage your project against the plan vigilantly. It’s easy for the plan to sit on the shelf, and for the team to go in their own direction. Instead, you need to lead the team by making sure they complete only those tasks which have been planned, and not other tasks which have cropped up along the way. So manage the project execution carefully. You can also save time in the Execution phase by:

Working your suppliers and contractors hard
Mitigating risks and issues before they affect the timeframe
Saving all non-critical tasks until after the project is complete
Not allowing unplanned tasks to be completed, unless critical
Not implementing change requests, unless they are critical.

Tip 4: Double up on Resources

Usually, the easiest way to shorten the length of the project is to assign more resources to it. However, this isn’t possible for many projects because they have a limited budget and a limited pool of resource.

But that's not to say that you can't double up on resources for the right tasks. It just means that if you do this, then other tasks will be under-resourced. So why would you do this?

In most projects there are tasks on the “critical path” that must be completed to deliver the project. If you assign more resources to these tasks than are necessary, you can usually complete them earlier than expected. And it makes sense that if every critical path task is completed faster, then the entire project will be delivered quicker than expected.

Tips 5: Get the Critical Tasks done first

In many projects the last 20% of tasks, take 50% of the length of the project. This is because the team have left the difficult tasks until the end, which happens to be when they are tired and need a holiday!

Instead, identify the tasks in your plan which are the most complex and challenging to complete. And if possible, tackle those tasks at the start of the project, when people are fresh and enthusiastic. You’ll find that they can complete those tasks in less time and to a higher standard of quality than if they were left until the end of the project. And with those difficult tasks completed, the rest of the project should be easier to deliver.

Was Your Project Really Successful?

2010-12-24T10:24:00.001+01:00

You have all read the stories about the large number of projects that fail. Depending on the report you read, half or more of projects fail - perhaps as high as 80%. According to the reports, the larger the project, the greater the chance that it will be a failure.

Let’s assume that the number of failed projects is 50% - the low number. What is interesting is to try to relate that number tomy personal experience. Where are all of these failed projects coming from? Can you say that half or more of the projects that you managed were failures?

It’s All in the Definition

The idea of a failed project starts with understanding the definition. You may have a perception of what it means to manage a failed project. Your company should have a definition as well, and if they do, your definition should be the same as theirs. One major concept that plays a key role is the idea of tolerances.

Define a Reasonable Cost and Duration Tolerance Level

If you estimate a project to cost $230,000, is your project a failure if the actual cost is $230,500? You missed your budget, right? Yes, but this gets into the concept of tolerances. If you delivered within $500 on a $230,000 budget, you should be lifted onyour manager's shoulder and paraded around the company as a hero.

Your company needs to establish the tolerance level that they consider to be reasonable for projects. For example, the tolerance level may be -10% to +15%.That is, if you deliver the project 15% over budget, it is still considered a success. For the $230,000 project, that means you could have gone overbudget by $34,500 and still have been considered successful. Thebaseline budget should also include any formally approved scope changes.For example, if your original budget was $200,000, and the client approved an additional $30,000 in scope changes, then the $230,000 is the number that you get held accountable for, plus your tolerances.

Normally there is some room for tolerances with your deadline as well. If the projects are internally focused, the end dates are in many cases arbitrary. Your original deadline must also be extended if scope changes were approved. Of course, not all projects have that flexibility. The YR2K software projects for instance, typically had to be completed by the first time they ran in the new year. A week late was not going to work.

Declaring Success From a Project Perspective

Once you understand your tolerances (if any), you can start to evaluate success from a project perspective. Generally, the project team members can declare success if:

The project is delivered within the estimated cost, plus or minus the tolerance.
The project was delivered within its deadline, plus or minus the tolerance.
All of the major deliverables were completed. (Some minor ones, or minor functionality, might not be delivered.)
The overall quality is acceptable. (It does not have to be perfect.)

Some companies also look at whether the project team was easy to do business with. That is, did the client and the project team work well together?For instance, was there good communication? If the client had another project (and a choice), would they ask you to work on it again?We call this "performance excellence".

Otherfactors may be important for specific projects. For instance in aconstruction project, safety might be a key success component.

A ProjectScorecard can be used to establish the formal criteria for success.

Declaring Success from a Company Perspective

Declaring success from a project perspective is normally what the project team is asked to be accountable for. However, from a company perspective, success would also be based on whether the company received thebusiness value that was promised. If the project was a failure from a project perspective, it is normally a failure from a company perspective as well. (Although this is not always the case.)

However, there are also many examples of projects that were successfully delivered, yet are not delivering the value promised. If the project team delivered successfully within tolerances, there is usually nothing else that can be done from their perspective. However, it is possible that the return on investment calculations were faulty, or the marketplace was misjudged, by the client and sponsor. It is also possible that this project was part of a larger initiative. Although your project may be successful, the overall, larger initiative may be a failure.

We believethat success against the project business value, as defined in theBusiness Case, is ultimately the responsibility of the sponsor - not theproject team.

Summary

Every organization should have some general rules about how to declare project success or failure. Your project isn’t a failure if you miss the budget by a dollar and deliver a day late. Normally a project will still be considered successful if it delivers within cost and deadline tolerances, and delivers all major deliverables within acceptable quality.This is what the project manager and project team can be heldaccountable for.

Action Items

2010-12-18T22:20:00.001+01:00

An action item is work that requires follow-up execution. By their nature, action items normally cannot be planned for in advance. They arise on an ad-hoc basis during meetings or as a by-product of working on something else. An action item is assigned because there is not enough knowledge, expertise or time to resolve the item at the time it originally surfaced.

In many cases, action items are trivial in nature, but in other cases they can require substantial work to complete. Action items need to be assigned, worked on later and completed. (If they are not going to be completed, they should not be called action items. Instead, simply note that the item will not be followed up on and then forget about it.) Examples of action items include forwarding specific information to someone, arranging a meeting and providing a quick estimate on a piece of work.

Sometimes an action item is established to investigate an area where there may be a potential problem. Because of this, action items are sometimes mixed in with issues. However, this is not right; an action item should not be confused with an issue. An issue is a problem which will have a detrimental impact on the project if left unresolved. An action item may lead to the discovery of an issue or a risk (a potential issue in the future), but the action item itself is not an issue.

There are two common approaches used to manage action items. The best approach is to document the items as activities in the project schedule. A resource and end-date are assigned as well, and the activity is then managed and tracked as any normal activity. In general, this is the better approach to follow, because it keeps the work items in one place and allows the project manager to enforce the discipline of knowing ‘if it’s not on the schedule, it will not be worked on.’ This approach also allows the project manager to see the impact of the action items on the schedule. For instance, you may have a small action item that is 3 hours of work. If you assign this action item to a person on the critical path, you will see the resulting delay to your project. This may result in you assigning the action item to someone else instead.

The second approach is to create a section on your meeting minutes for action items. Action items can be placed here if they are trivial (less than two hours) and they are scheduled to be completed by the next meeting. If you use this technique you can start each meeting with a review of the prior action items to validate that they are completed and then cross them off the list.

Understand the Difference Between Issues Vs Action Items

In many cases, project managers are not using the Issues Log to identify and track true issues. Many items that are classified as issues are really risks (potential problems) or just action items. Action items are activities that must be followed-up on at some time. They may or may not involve problems for the project. If you find that your Issues Log has dozens of items on it, you are probably tracking many action items. Because issues are large problems, there should not be many items open at any one time. If you find that your Issues Log is full of items, chances are that you are tracking much more then issues. This can result in true issues being hidden and not worked on as they should.

Be Proactive When Managing Projects with Unrealistic Deadlines

2010-12-18T22:12:00.002+01:00

If you are a project manager dealing with what you perceive to be an unrealistic deadline, the first thing you will want to do is discuss this with your sponsor to see if there are any factors that are driving the project deadline. For instance, there may be a business driver that is driving the deadline. There may be some event occurring that this project needs to support. On the other hand, sometimes managers set arbitrary end-dates just to provide what they consider to be stretch objectives. It does not necessarily make your challenge any easier, but you may find that by better understanding the reason for the deadline, you may have an easier time getting yourself and your team members motivated to achieve it.

Once you understand the motivation for the deadline date, there are project management techniques that can be utilized to increase the chances of success and better manage expectations.

Try to increase resources All projects require some time and cost to create the deliverables agreed to in the project scope. If you find that the time constraint is not in alignment with cost and scope, talk to your manager about increasing the resources that are available for the project. Adding resources to the project makes the cost go up, but may allow you to hit the deadline.
Reduce scope . Talk to your sponsor about reducing the project scope. See if there are features and functionality that they can live without for now so that you can deliver the project within the deadline specified
Identify and manage the deadline as a project risk. Utilizing risk management will help better manage expectations early in the project and also be a way to gather input and ideas for ways that you might be able to hit the deadline.
Manage scope with zero tolerance. On many projects, you start with an aggressive delivery date, and then the situation gets worse because the project manager does not effectively manage scope. If you are on a project with an unrealistic end-date to begin with, it is absolutely critical that you manage scope effectively and do not increase scope without an approved scope change request. Disciplined scope management will ensure that you only have to deliver what was originally promised, and that any approved changes are accompanied by a corresponding increase in budget and timeline.
Manage the schedule aggressively. In many projects, you might get a little behind but have confidence that you can make up the time later. However, when you start a project with the deadline at risk, be sure to manage the schedule diligently. You have no margin for error. As you monitor the schedule, treat missed deadlines as problems and work hard to solve the reasons behind the slippage.
Look for process improvement opportunities . Lastly, take an honest look at your schedule and your approach for executing the project. Talk to your team, clients, and manager about any ideas they may have for making the project go faster. This will get everyone thinking about being part of a solution. For instance, perhaps you could utilize a Joint Application Development (JAD) session to gather requirements more quickly than traditional interviewing techniques.

Although it appears that you are being held accountable for events and circumstances that are not within your control, you do have control over the processes you use to manage the project. First, see if you can balance the early deadline by increasing resources or reducing project scope. Second, proactively manage risk, scope and the schedule. Third, work with your manager, client and project team to uncover ideas and techniques that will allow you to deliver the project sooner that you might have first thought possible.

How to Deliver Your Projects Successfully

2010-12-17T23:26:00.001+01:00

These 5 tips will give you a head start:

Be honest

Always be totally honest and upfront with your customer right from the start. Tell them if their project is not feasible or if you don't have all of the resource, money and time needed to deliver it successfully from the outset. Set their expectations by telling them what you will deliver and by when. And if it eventuates that you can't deliver on your promises, then tell them about it immediately. By having an "open book" policy, you'll gain your customer's trust. If you involve them early enough, they will be more supportive for your project.

Manage through delegation

Managers often fall into the trap of believing that they can do things more efficiently than staff. Of course in many cases they might be right, but the problem is that they don't have the time to do everything themselves. So a smart manager always tries to delegate as much as possible to staff. It gives them the time needed to monitor the project and support their team. It's a tough ask, but even if you know you can do a task more efficiently than others, delegate whenever you can anyway.

Expect the unexpected

Always expect things to change and be ready for it when it occurs. People have ideas, your customer may want changes and the industry and technology change over time as well. It's not the change that's important, it's how you react to the change that counts. Always embrace change, but be wary of it. Question every change request and only when you're certain it's for the best, then implement it.

Become a great leader

When you save time by delegating your tasks, you have free time for leading and motivating your team. Do this by regularly communicating the project vision to your team, rewarding them for progress and recognizing their achievements. Gain their respect by showing them you care. Build team spirit by taking them to lunch regularly and talking about what they achieved together.

Work smart, not hard

Never start from scratch. Always give yourself a head-start by using tools like Project Management Templates. The templates boost the quality of your documents and they save you time and effort.

Create Risk Management Plan

2010-12-17T10:26:00.002+01:00

The Risk Management Plan describes how you will define and manage risk on the project. This document does not actually define the risks and the responses. This document defines the process and techniques you will use to define the risks and the responses. The information in this plan includes.

Roles and responsibilities.
This section describes the leading and supporting roles in the risk management process. The project manager typically has overall responsibility for risk management, unless the team is large enough that this role can be delegated to another team member – perhaps a risk management specialist. For a very large project, third-party risk management teams may also be able to perform more independent, unbiased risk analyses of project than those from the project team.
Budgeting.
Discuss your budget for risk management. Since you may not know enough to request budget for risk management you can also describe the process that you will use to determine a risk management budget estimate.
Timing.
Defines when the initial risk assessment will be performed, as well as how often the risk management process will be conducted throughout the project life cycle. The initial risk assessment should be performed early enough to affect the planning and estimating work. The detailed risk response plans should be revisited periodically during project execution to ensure they are working as expected.
Scoring and interpretation.
You should define risk scoring and interpretation methods appropriate for the type of the qualitative and quantitative risk analysis being performed. Methods and scoring must be determined in advance to ensure consistency.
Thresholds.
The threshold level is how you determine which risks are important enough to act upon. The project manager, client, and sponsor may have a different risk threshold. The acceptable threshold forms the target against which the project team will analyze risks. Typically, risks above the threshold will be responded to. Risks under the threshold will not be responded to (or will just be monitored).
Communication.
Describe how the information on risk will be documented and communicated. This includes the risks themselves, the risk responses and the risk status. If you have already covered this information in the Communication Management Plan, this section may be bypassed.
Tracking and Auditing.
Document how all facets of risk activities will be recorded for the benefit of the current project, future needs, and lessons learned. Also describe if and how risk processes will be audited.

These are examples of the content that would be included in the risk management plan.

Assumptions and Risks

The quick definition for an assumption is that it is a “statement believed to be true”. In other words, you are not 100% sure if it is a fact, but you believe it to be true for the purposes of planning your project.

Projects need assumptions. You cannot delay a project while you try to be 100% certain of all aspects. In fact, it is not possible to be 100% sure of every aspect of a project. In some cases you need to “assume” that things will turn out as you expect, and continue planning based on those assumptions.

Another way to look at assumptions is their relationship with risks. Assumptions are very much related to risk, and in fact are simply low-level risks. They both start with the same premise. They are both future events or conditions that will impact your project. In both cases, there is a probability of occurrence and an impact to your project. The difference between an assumption and risk has to do with whether the combination of probability and impact is acceptable to you or not.

Let's take an example of a common statement that is included in many Project Charters – that “the resources needed for this project will be available when needed.” What kind of a statement is this? Most people would say it is an assumption. After all, when a project starts, you always assume you will get the resources you need.

However, is it always an assumption? Can you imagine starting a project where there was a realistic possibility that they would not be ready when you need them - perhaps because another project needed to finish first? It is not too difficult to imagine that scenario. In that case, the same statement would definitely be a risk - not an assumption.

The key point is that the same statement might be an assumption or a risk depending on the circumstances of your particular project. The difference between an assumption and risk is whether the combination of probability and impact are acceptable to you or not. If the combination of probability and impact are not acceptable to you (that is, the combination is too high), it can be stated as a risk. If the combination of probability and risk are acceptable, it can be an assumption.

One way to identify important assumptions is to perform a risk assessment and look at all the low-risk items. Most of these low risks are not worth mentioning, but some will have significant implications if events do not turn out as you think. These are the ones that you can document as assumptions.

Use Special Techniques for Virtual Teams

2010-12-04T00:35:00.002+01:00

In the past, a project team almost always resided in one location. The reason is obvious: it was not easy to communicate and collaborate with people that were not in the same physical location. Today, it is still common for a project team to be in relative close proximity. However, it is also becoming more and more commonplace to have team members physically located in many different places. This may be because of pulling in resources from other company offices. In some cases, you may have team members that are teleworking from home. In other cases, you may be partnering with a third-party company - perhaps even internationally.

All of this is more common today because of advances in technology and software. People can access your company's computer network remotely with almost the same speed as if they were in the office. Software is available to share documents and make updates available real-time to the rest of the team. The team can get together as needed using phone conferencing. You can even see each other if you like using teleconferencing or utilizing video technology over the web.

That is all good news. The not-so-good news is that it is still easier to manage a team when the members are located together. There is no technology that can take the place of reaching out and touching someone or talking to them face-to-face. If you have a project team that is dispersed, you should identify it as a risk when the project is being defined. It is not an issue, since it is not causing a problem right now. However, there is some risk that this situation may cause a problem in the future. Then, put together a Risk Management Plan that will mitigate the situation and make sure that problems do not occur in the future. Consider the following ideas:

Make sure everyone has the right technology.
Make sure that your remote team members have the right hardware, software, and other equipment to get their work done. For example, if some team members are working from home, a 14.4 modem probably will not cut it. You really need fast access connections.

Utilize collaborative technology.
There are many products on the market that allow for much easier collaboration among people who are in different locations. Much of this is web-based today. For instance, you can get software that allows everyone to participate in a common meeting on the web, including viewing and changing common documents.
Make sure people have the right attitude.
Both the project manager and team members must be especially diligent and sensitive to collaboration and teamwork concerns when part of the team is remote. It is easy for a remote worker to fall into a mode where he is isolated from what is going on with the rest of the team. People who are working remotely must be proactive communicators and must be especially good at working independently and meeting their deadlines.
Establish good communication processes.
The project manager needs to develop a proactive Communication Management Plan to ensure the dispersed team works well together. For instance, if possible there should be regularly scheduled meetings where the remote workers attend in person. If the team members are in different cities or different countries, look for common times when you can have a videoconference or audioconference.
Plan the handoffs.
Sometimes multiple people in different locations are working on the same, or related, deliverables. In these cases, the project manager may need to establish rules for handoffs, especially if different time zones are involved. Don't leave the handoffs to chance. Set up processes to ensure that work on shared deliverables transitions smoothly from one person (or team) to another person (or team).

The bottom line is that the project managers must recognize that there is inherent risk associated with remote team members. To a certain degree, the risk gets larger the further away they are because you not only deal with distance, but also time differences. However, a proactive project manager can work through the difficulties by looking holistically at the people concerns, process concerns, and technology concerns. A Risk Management Plan can be set up to mitigate the risk and ensure that the dispersed team works well together for the common good of the project and the team.

Project Management for Dummies

2010-11-30T20:57:00.000+01:00

You can manage any type of project, by taking these 5 steps:

Step 1: Set the goals

The 1st step is to gather your team together on site and set the goals. This means stating clearly what they have to achieve, by when and how they are going to do it. At this meeting, you need everyone on board, offering you their full support. Get them pumped and ready for action!

Ask your customer to come to the meeting and explain why the solution that the project will deliver is critical to their business. Get your customer to explain why the timescales are also important and the level of quality that must be achieved. Only with an understanding of the solution, timescale and quality targets will the team fully realise what it is that they have to achieve and be motivated by it.

Tip 2: Plan, plan, plan

The next step is to plan a course of action to achieve your goals. Work with your entire team to identify all of the major tasks that need to be completed. Estimate how long each task will take and create your project schedule. Then assign resource to each task so that everyone in the team knows what has to be done and by when.

Run the plan past your customer to get their feedback. Only with a rock solid plan will the team have clear direction going forward.

Tip 3: Measure, Monitor and Control

Then start measuring progress against your plan and monitoring it weekly to ensure you're always on track.

You also need to control any change requests. This is when someone requests changes to your scope or deliverables. They might be a great idea at the time, but unless they are going to save you time or money, then wherever possible try and park them and move on. Changes to project scope often kill the best laid plans.

Tip 4: Communicate clearly

You know whether you're ahead, on track or behind - but do your team? You need to keep them and your customer properly informed, if you want their full buy-in and motivation.

Also, report your project status to your customer weekly. Hold regular project status meetings with your team to keep them informed of progress against the goalposts and what lies ahead.

Tip 5: Work Smart

You have limited time and resources to deliver your project, so you need to work smart. Manage your time carefully. Use "To Do Lists" to prioritise your work. Limit the number of meetings you have and keep telephone calls short. Only work on prioritized tasks. If something arises that is non-critical then keep a record of it and move on.

You Must Build a PMO that Makes the Most Sense to Your Organization

2010-11-29T23:55:00.001+01:00

There are almost as many varieties of PMO as there are companies. There are strong PMOs and weak PMOs. There are some that have many responsibilities in the organization and some that have only a few. Some companies rely on the PMO to be responsible for all areas of project management and project execution. Other companies only want the PMO to provide a consolidated reporting view of all the projects in the organization.

Before you can jump in and start up a PMO, you must first define what the PMO will look like. Without this foundation, all of the other work you do will be in jeopardy.

One way to create your PMO is through a formal organizational definition. The value of defining a logical organization is twofold. First, you gain clarity and agreement on what you are doing and why. This information is communicated to clients, stakeholders and your own staff so that everyone starts off with a common set of expectations. Second, this exercise provides a framework for the PMO to guide decision-making in the future. For instance, you would not want to undertake any projects that did not help you achieve your organizational objectives. Likewise, major decisions can be evaluated based on whether they fit into your strategy.

Building a Logical Organization

The term "logical organization" means that when the definition is complete, the organizational structure will only exist on paper. Once the logical organization is defined, you still need to actually staff the PMO at the right level to support the logical organization. The following major components are used to define your logical PMO. Many companies have the expertise to perform this definition by themselves. However, defining missions and strategies is something that you do not do every day. That is why consultants are sometimes brought in to assist. There are consultants that specialize in these organizational assessments. They can facilitate the definition process and make sure that the resulting logical organization provides a firm foundation for the subsequent staffing and project execution.

Mission. Describes what the PMO does, how it is done, and for whom. It is a very general statement, usually aligning the PMO to the value it provides to the business. An example of a PMO mission statement is "The Acme Project Management Office (PMO) implements and supports project management methodology to enable our organization to deliver projects faster, cheaper, with higher quality and within estimates and expectations."

Strategy. There may be many ways to achieve your mission. A strategy is a high-level set of directions that articulates how the organization will achieve its mission. Defining a strategy also helps get the PMO aligned in the same direction as strategies in the rest of the company. Strategy defines how you will do things over the long-term - say three years - and is used as an overall framework for the more detailed tactical decisions that are made on a month-to-month and day-to-day basis.

Sponsor. All organizations do not have a sponsor, but a PMO typically does. In this respect, a PMO is similar to a project and, in fact, many PMOs are established with a project. The sponsor is the person responsible for the PMO funding, and in many cases the sponsor is the manager that the PMO reports to. Sponsors are important for all initiatives, but they are absolutely critical for a culture change initiative such as this.

Clients. Clients are the main individuals or groups that request and utilize the products and services your organization provides. (These people may also be referred to as customers.) While there may be many stakeholders (below), it is important to recognize who the clients are. They should be the ones the PMO focuses on - to help them meet their project and business objectives.

Stakeholders. These are the specific people or groups who have an interest or a partial stake in the products and services your PMO provides. Internal stakeholders could include organizations you work with, but who are not directly under the PMO umbrella. External stakeholders could include suppliers, investors, community groups, and government organizations.

Objectives. Objectives are concrete statements describing what the PMO is trying to achieve in the short-term, perhaps up to one year. The objectives should be written at a low level, so that they can be evaluated at the end of the year to see whether they were achieved or not. A well-worded objective will be Specific, Measurable, Attainable/Achievable, Realistic and Timebound (SMART).

Products / Services. Products describe tangible items that the PMO produces, and are typically produced as the result of a project. Services refer to work done for clients or stakeholders that does not result in the creation of tangible deliverables. Services provide value by fulfilling the needs of others through people contact and interaction. The PMO achieves its objectives through the creation of products and the delivery of services.

Transitional Activities. Transitional activities are the specific activities and projects that are required to implement the physical PMO. If the PMO is new, these activities describe the work required to build and staff the new organization. This does not imply the creation of a full workplan, but it includes the immediate activities required to get you to the point that the PMO workplan can be put into place.

There are other aspects of the organization that can be defined as well, including the PMO vision, principles, goals, skills, roles and responsibilities.

Summary

A PMO should be established based on a need to help the organization in project management and project execution. There are many ways that a PMO can be established. The correct way for your company can be determined with an exercise to create a logical organization definition. When you have a consensus on the definition, the PMO has a much better chance of success and of meeting sponsor, client and stakeholder expectations. Once the logical organization is approved, the staff can be put into place to build the physical organization.

Tips for Running Project Meetings

2010-11-21T00:44:00.002+01:00

Everyone dislikes meetings that drag on. So your job is to make it focused, highly driven and to add a sense of purpose. If you do this, then you’ll boost team motivation and morale. Here are 5 tips to help you...

Tip 1: Plan wisely

To make sure you get the most out of your meetings, you need to plan them wisely. Prior to each meeting, write down 3 goals that you want from the meeting. Here are some examples:

"I want the team to know we're on track"
"I want any issues or risks to be raised"
"I want them to feel valued and motivated"

Then you need to work out how you're going to achieve your goals. The next few tips will help you with this...

Tip 2: Open and close carefully

Like in theatre, people most remember the opening and the closure the most. So open and close your meetings carefully. When you open the meeting, tell them what the purpose of the meeting is, what you want to get out of it and why it's important. This gets their attention and sets the scene. When you close the meeting, tell them what has been agreed / achieved in the meeting and the next steps going forward.

Tip 3: Control the conversation

You need to be in complete control of the meeting at all times, to ensure that:

The meeting follows the agenda
You never get stuck on a single issue
One person doesn't dominate it
Everyone has their say

Start by standing or sitting in a prominent place in the room. Raise your voice a little to add presence. Jump in frequently when people talk too long. Be polite but strong. Control the meeting as a coach would control a football team - by constantly watching, listening and directing the team. If possible, ask someone else to record the minutes. This gives you the time needed to control the conversation so that the agenda and your 3 goals are met.

Tip 4: Park it and move on

Often in meetings, a single issue can consume the majority of the meeting time. If the issue is not related to your specific meeting goals, then tell the team to "park it and move on". Record the issue on a whiteboard or paper and address it with the relevant team members separately after the meeting. This keeps your meetings short and focused.

Tip 5: Keep it action orientated

Projects are all about "getting things done". So make sure that where possible, every discussion results in an action to be completed. Focusing on the actions that are needed, is a great way of reducing the length of meetings.

Inherent Risk Factors

2010-11-17T20:48:00.001+01:00

Inherent risks are those that exist based on the general characteristics of the project. These are risks that can appear regardless of the specific nature of the project.

None of the inherent risks mean that the project is in trouble. Many of these risk factors will be rated as low or medium-level risks. Even if you identify an inherent risk as high, other project factors will come into play as well. For instance, the checklist below states that a large project is inherently more risky that a smaller project. This is generally true. However, an experienced project manager can mitigate many risks associated with large project size. Also remember, if your project falls into a high-risk category, it does not mean you will not be successful. It only means that you should put plans into place to manage the risks.

This table below identifies characteristics that may imply risk, as well as criteria for knowing if it is high-risk and low-risk. Depending on where your project characteristics fall, you can evaluate whether your risk is high, medium or low. This type of checklist can be especially valuable if your organization customizes the risk characteristics and risk criteria and makes them available to all project managers. For instance, you may find in your organization a project of less than 5,000 hours is considered low risk, while one that is 20,000 hours or more is high risk.

If your projects have an end-of project review meeting, the teams can look back and document the risks the project faced, the risk response plan the team executed and the results. The results can be consolidated and summarized in a Risk Factors Checklist that is based on the key learnings and best practices of your own organization.

In the table below, medium-level risks would fall somewhere in the middle of the high and low risk. For instance if your team size is 15, it would be a medium-level risk. Likewise you could have a medium risk if your project scope / deliverables are better than “poorly-defined” and worse than “well-defined”. This could be the case if some deliverables were poorly-defined and some were well-defined.

The following checklist can be used to determine whether there are inherent risks on your project that you have not considered yet.

Characteristic	High Risk	Low Risk
Total effort hours	Large project > 2500 hours	Small project <>
Duration	Longer than 12 months	Less than 3 months
Team size	Over 25 members	Fewer than 5
Number of clients or client organizations	More than three	One
Project scope / deliverables	Poorly-defined	Well-defined
Business benefit	Not clear (should not start the project)	Well-defined
Project team and client business knowledge	Neither the project team nor the client have solid business knowledge	Both the project team and the client have solid business knowledge
Requirements	Very complex, hard for client to define	Easy for client to define
Dependency on other projects or outside teams	Dependent on three or more outside projects or teams	No more than one dependency on an outside project or team
Project sponsorship	Unknown (should not start the project)	Identified and enthusiastic
Client commitment	Unknown, passive	Passionate
Changes required to existing procedures, processes and policies	Large amount of change	Little change
Organization structures	Large amount of change	Little or no change
Project manager experience	Little experience on similar projects	Similar experience on multiple projects
Physical location of team	Team is dispersed at several sites	Team is located together
Use of formal methodology	No formal methods or processes	Standard methods in use
Technology	New technology is being used for critical components	No new technology required
Response time	Very short response times are critical	Normal response time is acceptable
Data quality	Data is of poor quality	Data is of good quality
Vendor partnership	Have not worked with the vendor before	Have a good relationship with the vendor

This table is an example of the types of inherent risks that can exist on projects. There are others as well that form the starting point for identifying risks on your project.

Techniques to Get a Project Back on Budget

2010-11-05T00:04:00.002+01:00

Project managers need to manage schedule and costs on their project. The sponsor has agreed to pay a certain amount of money for a certain solution. If the solution ends up costing more than anticipated, the solution may or may not make as much business sense.

Managing the budget is vastly different from company to company. In many organizations, project budgets get fixed early and project managers have very little flexibility dealing with changes to these budgets. After the budget is allocated, it may take much more work to try to have it increased if the work is costing more than anticipated. However, in just as many organizations (perhaps more) the budget is meaningless to the project manager. These organizations typically use internal resources for projects and they do not have the accounting processes to manage project costs. The project managers try to manage the schedule to hit the estimated end-date, but they have no responsibility to estimate or manage project costs.

<>If you monitor costs regularly, you should know very quickly if you are trending over your budget. This control process is somewhat more difficult than managing the schedule, because there could be a variety of reasons why your financial information is not as good or as accurate. With scheduling, you know right away if you missed an end-date. With the budget, you may not always know.

There are a couple reasons that managing the budget is more complex.

1. First of all, you rarely spend money at a constant rate. So, you need to understand what you expected to spend during the period, as well as what you actually spent. In most companies, financial information also comes in on a lag. For instance, you might not know the financial status of your project for the current month until well into the following month when the budget reports are released.

2. Timing is another problem. You need to know when your company recognizes expenses in your financial systems. You might recognize an expense when you receive an invoice, or perhaps not until you pay an invoice, which may be much later. If your company uses purchase orders, your project may actually get hit with a project charge when the purchase order is generated, even if the actual invoice is not paid for weeks later. Depending on your budget, this may cause expenses to hit early and may make it appear that you are trending over budget, when really you are not. The expenses are just hitting your budget earlier than you had planned.

If you find your project is trending over budget, you must first validate the cause. If you can determine the cause, you will have a much better idea of what options are available to try to get back on track. There are a number of techniques you can apply to try to rein in spending to get back within your budget.

Swap Human Resources

If you were trending over your deadline, you may want to swap resources to get your project back on schedule. Usually you want to swap inexperienced and less productive resources for ones that are more productive and more experienced. However, when you are dealing with an over-budget situation, you have a different motivation. You may need to see if there are less expensive resources that can be applied to activities instead of higher paid resources. In fact, if cost containment is more important then the deadline, you may be willing for the work to take a longer time if it ultimately can be completed successfully at a reduced cost. This technique could also be used to replace a contract resource with an employee resource, if the employee would end up costing less for your project.

Eliminate or Replace Non-Labor Costs

Just as with people, it may be possible to utilize less costly materials, supplies or services than what was originally budgeted. For instance, you may ask travelers to stay at a discount hotel chain instead of more upscale accommodations. You can see if team members can utilize existing upgraded hardware instead of new machines. You can substitute less expensive computer-based training, or team mentoring, for previously scheduled formal training classes. You may have to send one person on a traveling activity, instead of two that were previously planned.

In each of these cases, you are attempting to satisfy the original need, but by using a less-costly alternative.

Work Unpaid Overtime

This option takes advantage of the situation where your employee staff does not get paid for overtime. It is usually the first place to look and a team may rally around overtime to get a project back on budget in the short term. The logic is that you can get more work done for the same cost, since you do not have to pay your internal resources for the overtime. If you are toward the end of the project, you also may be able to issue comp-time after the project is completed. However, this is usually not a good solution for very long.

Re-bid or Renegotiate External Contracts

Refer to the TenStep Process Procurement Extension for more information on this topic.

Scope Back the Work or Ask for More Budget

One option that is usually available for both an over-budget and over-deadline situation is to look at the work remaining and negotiate with the client to remove some of it from the project. If the remaining work is all vital to the solution, this discussion still might need to take place as a last resort. There may be options to complete this project on-budget with less that 100% functionality, and then to execute a follow-up project to complete the remaining requirements.

The other alternative of last resort is to request additional budget and see if you can complete the original work requested if you are given more money.

The key point is that you don’t jump to this alternative as soon as you start to trend over your budget. You should first try the other multitude of proactive options available to try to get back on budget. You should only fall back on reducing scope or asking for more money if all the other tools and techniques fail.

How to Kick Start Your Project

2010-10-23T14:16:00.005+02:00

Most Projects Managers get tired at some point in their project. After all, managing people, money and time is exhausting. But if you're not at the top of your game for the whole length of the project, then your team can get stressed and timeframes can start slipping. So here are 5 tips for kick starting your project to rejuvenate it and give it a new lease of life...

Tip 1: Stop and get a grip
Projects are always ahead in some areas and behind in others. Stop and take the time to get a firm handle on the project progress. Make a list of all of the areas that you're behind in. Then prioritize the list and calculate the amount of effort needed to get them back on track. Are there any tasks that can be completed by others outside your team? If there are non-critical tasks that you can outsource, then now is the time to consider it. Use whatever resources you can find to complete these late tasks as soon as possible.

Tip 2: Rework the plan
Once you've caught up, revisit your Project Plan. Update every task in the plan and recreate your schedule ahead. You need to revitalize your team and to do this, you need a newly worked project plan that shows how you're going to deliver the rest of the project on time. This will boost motivation and enthusiasm for completing the revitalized plan. Especially if your team can see that it's actually achievable.

Tip 3: The Road Ahead
Now that you have a crystal clear plan ahead, you're ready to get the team behind it. Take your team out for lunch. Walk them through the remaining challenges and the timeframes in which they must be achieved. Try not to talk about the prior period or any failures to date. Instead, be positive and focus on the road ahead to gather their support. If possible, ask a customer to come along, to impress on your staff what it is that they need to deliver and by when. Tell them you're proud of them and what they're capable of achieving.

Tip 4: Individualization
The trick now is to make each person feel like they are a critical cog in the wheel. Meet them individually, reward their successes and recognize achievement whenever you see it.

Tip 5: Quick wins
A winning team like to know they are winning right from the start. Focus on delivering a couple of critical tasks early, then shout about the success. Then get more quick wins under your belt and shout out about your successes again. This creates the feeling of achievement and it creates momentum in the team. Sure, the project may not be finished until you've crossed the finishing line, but half the fun should be in getting there.

By taking these 5 tips, you can kick start your projects to boost motivation to an all time high.

How to Kick Start Your Project

2010-10-23T14:16:00.003+02:00

By taking these 5 tips, you can kick start your projects to boost motivation to an all time high.

Projects, Programs, and Portfolios Defined

2010-10-17T17:58:00.000+02:00

Many people hear the terms projects, programs and portfolio, but are not sure what they all mean and how they fit together. Project managers probably have a good sense for what a project is, but the other two terms might be a little fuzzy.

In general, you can divide all the work of a corporation into projects (large and small) and support (ongoing operations). Administration may be considered separately, or as a part of support. At a high level,

Projects are where all the new work gets done, including new enhancements. They have a beginning and an end, have specific objectives and deliverables, and are unique.
Programs are a way to divide huge work efforts into a smaller set of related projects, some of which are executed sequentially and some of which are executed in parallel.
Portfolios are a collection of related and unrelated programs and projects, as well as related support. The person who manages a portfolio might be called a Director or a Vice President, since the job typically involves the overall management of the work, people, budget, vendors, etc., many times on behalf of a department or division.

This is all complicated because the terms and roles might mean different things at your company. Take the project manager role. The Project Management Institute actually defines five major types of project managers, based on the type of organization and the type of project being executed. Each has a different level of authority and responsibility in the organization. Each also relates differently with a different set of functional, or administrative, managers. At your company (and others), the project manager may, in fact, be seen as more of a coordinator and have few real responsibilities other than administrative. You may use the program manager role as the one with real authority and project management responsibility. You may also use the term program management to define the level where you actually control budgets and staff. In other companies, those could all be the responsibility of a strong project manager.

In general, then, these definitions may not be universally accepted, but they are consistent with how many companies view the terms and what the literature describes.

The literature is filled with information on project management and the role of a project manager. Projects, by their definition, have a defined start and end date. There is a point in time when the work did not exist (before the project), when it does exist (the project), and when it does not exist again (after the project). This is the key determinant of whether a piece of work is a project. However, other characteristics of a project include a defined scope, finite budget, specific end result (or deliverables) and assigned resources. Another characteristic of a project is that the work is unique. Even if a project is similar to another one, it is not exactly the same because circumstances change and because things are always different when you are dealing with people.

There is not nearly as much information on program management because typically a program is defined as an umbrella organization over a group of related projects. Let’s take an example of a program to send a man to the moon. The Moon Landing Program is made up of dozens (or hundreds) of projects dealing with all the specific work required to take a man to the moon over a seven-year timeframe. No work gets delivered at the program level. All the work is done in the underlying projects. The program is there to help set overall direction, help start new projects, make sure the projects are progressing as they should, etc. But all the action (hence all the literature) is still focused on the project.

Portfolios are similar to programs in that they encompass a set of projects, but they are also much broader. A portfolio will typically be the umbrella structure over a group of related and unrelated projects. The portfolio may also contain support groups. Usually a portfolio encompasses all the work associated with a specific company business unit or a specific technology. The person in charge of the portfolio is usually a functional manager, reporting upward in the company’s management hierarchy. However, again, work is not done at the portfolio level. Instead the work is done on the projects that are within the portfolio.

In summary, you will find a lot of information on projects, but not as much on programs and portfolios. Both of them are typically thought of as the umbrella structures to coordinate lower level projects. The actual work is done at the project level and managed by a qualified project manager with the right level of authority and responsibility.

Openly Address Issues that You Cause

2010-10-09T11:03:00.003+02: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.

A Weighting System

2010-10-09T10:44:00.004+02:00

An Objective Project Scorecard May Need More Complexity (Part 2 of 2)

As you take more and more factors into account to determine project success, the last area you need to address is some type of weighting system. This will be necessary because not all of the performance factors are of equal importance. For instance, it may be vital that your project be completed by a certain date, and that may be more important than whether you hit your budget target. In fact, you may have to overspend your budget to make sure you hit the deadline. So, on that project, meeting the deadline date should be weighted more heavily than meeting the budget target.

The way you establish an overall weighting formula is to start off with a maximum point total and divide the achievement of that maximum total into the number of success criteria. Let’s look at an example of a project with five success criterion. The achievement of all the success criteria results in a 100-point maximum. In other words, if the project team did everything perfectly, their total score would be 100 points. Let's also say that the five criteria are deadline, budget, quality, client satisfaction and sponsor rating of success. You would develop a scorecard grid, as follows:

1. Deadline, 25 points, complete by December 31
2. Budget, 10 points, $250,00 plus or minus 10%
3. Quality, 20 points, five questions survey averages at least 3.5 out of 5
4. Client Satisfaction, 20 points, five question survey averages at least 3.5 out of 5
5. Sponsor rating of success, 25 points, three question survey averages at least 3.5 our of 5

Total possible points - 100

You can get very sophisticated with this scorecard system. However, you will find that each attempt to get more fact-based and less subjective requires you to get more and more precise in defining the overall scorecard rules. For instance, the following needs to be taken into account as you get more sophisticated.

You must define what the numerical total represents.

For instance, on the project above, you could say that any final rating over 80 represents success. In that case, the project above was successful. If there was a bonus to be paid for project success, you could say that a full bonus would be paid for an overall rating of 80 or above. No bonus (or a partial bonus) would be paid for a score under 80.

You would define whether partial credit is given to scores that do not meet the scorecard criteria

For instance, in the example above, the project went over budget by $20,000. This was within the acceptable range of plus of minus 10% ($225,000 to $275,000), so the team received full credit of 10 points.

On the other hand, the overall quality rating was 3.2 and the target was 3.5. The question is whether the project team receives zero points since they missed the criteria, or if they receive partial credit for getting close. In this example, the team received 10 points, or half the possible total. You could imagine that at some point; say under 3.0, the team would not have received any points. If the team had missed that criterion, their total points for the project would have fallen to 75. If the success target was 80, the project would have been viewed as a failure, even though the rest of the criteria were hit successfully, including an overall 4 out of 5 rating from the sponsor. That shows why it is important to have proper weighting for your project. If you are going to have this level of algorithmic objectivity, it is important that the team really focus on the important scorecard success factors. This is a powerful incentive.

You must decide whether the weightings represent the maximum allowed, or whether the team can score higher.

For example, on your Sponsor survey criteria, perhaps you could establish a rule that says that you receive an extra 10 points for every .5 over your target. In our example above, since the final score was 4.0, the team would have received 35 points for this criterion, which represents the target 25 points, plus an extra 10 points for exceeding the target. Again, if you allow extra credit, you must determine what that means. For instance, if you were paying a bonus on successful completion of the project, going over 100 may mean that the team receives a higher bonus, say 110% of the target bonus.

The Success Formula Must be Known Ahead of Time

The key to these rating systems is that they have to be defined ahead of time so that the entire team can focus on the areas that are important. If you don't finalize the criteria until the project is already started, you may find out that you are too far behind in certain categories to achieve them. If the team feels that they do not have a chance to achieve the targets, the scorecard will result in a lot of negative feeling and poor morale, which is just the opposite of what you are trying to achieve.

The other aspect of having the scorecard built early is that it gives the project team time to adjust if there are problems. For instance, in the project example above, let's assume that the project duration is around nine months. The project manager may send out the quality survey and the client satisfaction survey after three months and after six months. That way, if the survey results are not coming as expected, the project team can determine the cause, and the entire team has time to correct the problems before the project is completed. This is part of a process improvement process. If the scorecard is not completed early and the team does not have time for interim surveys, the first time they see survey results is when the project is completed, which is too late to take any corrective activity.

Summary

Is your project a success or not? Simple metrics are easy to capture, but they do not leave much room for telling the entire story on a project. In general, the simpler your metrics are, the harder it is to look at shades of gray. If your success is based strictly on your sponsor’s feedback, you can end up in an all-or-nothing situation. The more aspects of the project you take into account, the more sophisticated you need to be in terms of how the separate criteria get put together for the overall success level.

If you have multiple success criteria, you will find you also need to put together a weighting scale. When you were in high school, your final grade was determined by some sort of formula based on your test scores, quiz scores, homework, attendance, etc. For the most part, everything was numeric based, and could all be calculated based on the raw scores. Pretty simple, and no surprises.

On a project, however, it is not that simple, since you have to take into account client satisfaction and quality – both of which get into subjective data. Your project scorecard can try to compensate for the subjectivity, and attempt to make the process as objective and mathematically driven as possible – just like your high school grade.

However, the more objective and fact-driven you attempt to get, the more complex and intricate your scorecard data collection and interpretation needs to be. Your scorecard criteria should be balanced and comprehensive. You should have targets that are challenging but reasonable. You also need to weight the various aspects of the scorecard to make sure that the relative importance is established. If you do not think through these implications, you may have confusion and disappointment at the end of the project as your scorecard results are subject to multiple interpretations.

Create a Project Plan in 3 easy steps!

2010-10-01T11:31:00.002+02:00

The Project Plan lists all of the activities required to complete the project as well as the milestones, dependencies, resources and timeframes involved. The following diagram depicts the 3 critical steps involved in creating a Project Plan:

To create a Project Plan, you first need to define the Work Breakdown Structure ("WBS"). The WBS lists each of the phases, activities and tasks required to undertake a project. You will then identify the resources required to carry out each activity listed. And finally, you will construct a Project Schedule which describes the flow of tasks and the timeframes involved in completing each task specified. A more detailed description of each of these steps follows:

Step 1: Define the Work Breakdown Structure

The first step taken when creating a detailed Project Plan for your project, is to create a comprehensive Work Breakdown Structure (WBS). The WBS lists all the phases, activities and tasks required to undertake the project. Identify and describe each phase, activity and task required to complete the project successfully. Depict the order in which the tasks must be undertaken and identify any key internal and external project dependencies. Also list the critical project milestones, such as the completion of key project deliverables.

Step 2: Identify the Required Resources

Having listed all of the tasks required to undertake the project, you now need to identify the generic resources required to complete each task. Examples of types of resource include: full-time and part-time staff, contractors, equipment and materials. For each resource type, identify the quantity required, the delivery dates and the project tasks in the WBS that the resource will be used to help complete.

Step 3: Construct a Project Schedule

You have now collated all of the information required to build a detailed Project Schedule. To construct your schedule, you need to:

List the phases, activities and tasks
Sequence the phases, activities and tasks
Add key internal and external dependencies
Allocate relevant completion timeframes
Add additional contingency to mitigate risk
Assign resources required to complete tasks
List critical delivery milestones
Specify any assumptions and constraints

And there you have it! By following these 3 simple steps, you can create a comprehensive Project Plan to increase the likelihood of success of your project.

An Objective Project Scorecard May Need More Complexity (Part 1 of 2)

2010-10-01T11:16:00.000+02:00

When a project ends, many project teams struggle with whether they were really successful or not. Knowing how a project ended compared to its deadline and budget only tells part of the story. If a project team delivers a poor quality product on time and within budget, it still should not be viewed as a success. On the flip side, if quality is extremely important, the sponsor may consider the project a success if the deliverables meet the quality criteria, even if the project was also late and over budget.

The term “scorecard” is used to describe the criteria that determine whether the project was a success or not. The term “balanced scorecard” refers to having a rounded set of success criteria that take into account a number of different aspects of delivering a solution. Scorecards allow you to establish and gain agreement on the important criteria that signify how successful a project is.

Once you start thinking about your success criteria, however, there is an important factor to consider. The more you strive for accuracy and objectivity in your success criteria, the more complex and time consuming the data gathering and interpretation will become. Let’s look at ways to gauge overall project success, starting at the very simple and moving toward the more complex.

Simple Sponsor Survey – Yes or No

Perhaps the simplest way to know if you were successful is to simply ask the client sponsor whether the project was a success or not. This is the most direct and the sponsor is usually the person who ultimately must judge success. The sponsor would take into account the budget, deadline, quality, etc., and also make a mental determination of which criteria was most important.

And there you have it - a straight "yes" or "no" from the sponsor to the question of whether or not the project was a success. All or nothing! What can be simpler?

Allow a Range of Survey Answers

The problem with the simple "yes" or "no" answer is that it is black or white (all or nothing) and does not leave any room for shades of gray. Usually the sponsor will be happy about how some things turned out and disappointed in other things. The sponsor may not be willing to be slotted into a simple "yes" or "no" answer.

A method that allows more options is to still ask one question, but allow the answer to be expressed in a range. For example, you can ask the sponsor "How satisfied were you with the overall success of the project?" and allow them to express their answer on a one through five scale (or one through ten). Now the sponsor has some discretion. If they are totally satisfied, they can score the project a five out of five. If they were happy about most things, but unhappy about some, they can rate the team a four out of five. This allows the sponsor to provide a little more of a gray area, while still keeping things very simple.

More Comprehensive Survey

You will probably discover that asking one question is just not enough, especially if you want to validate that certain specific behaviors are taking place. To gather more feedback, your survey just needs to have more than one question. Instead, you break overall success into a number of components. For instance, you may have multiple questions that ask, on a scale from one to five, how satisfied the individual was with:

How the team communicated

Whether the deliverables produced were of high quality
Whether the team responded in a timely manner
Whether the team was knowledgeable in the business area
Etc.

This survey can also be completed by a wider range of people. You could ask the sponsor and a number of other impacted stakeholders to provide feedback.

Adding Multiple Success Criteria

Of course, these survey metrics do not have to stand on their own. You can combine them with other basic information regarding budget and deadline to determine the overall success of the project. As an example, the team may have been within 5% of budget and hit its deadline. They may also receive an overall consolidated 4.1 out of 5.0 on the survey. The question then is whether this is a success or not. There is certainly much more information available. However, in addition to setting the success criteria, the project team must also establish a reasonable target number. For the budget and deadline, this probable means that you completed the project within your estimates – plus or minus your tolerance levels. For survey results, you could establish a target level, for instance, an average of 3.5 on a five-part scale.

This leads us to one more level of complexity. If you have multiple success criteria, how do you combine them all together? If you were utilizing cost, delivery date and a client survey, how do you know what is most important. If your deadline was extremely important, for instance, you may find that the project was successful if it hit the deadline, even if it was over budget. This gets into the area of weighting the scorecard success criteria.

Make Sure You Have Client Agreement as Well

The project team and the client must agree on the overall scorecard ahead of time. You do not want to be in a position where the project team is declaring success at the end of a project, but the client feels the project was unsuccessful. If you have an agreement on the scorecard, both the project team and the business client should have common expectations in terms of overall project success.

Qualitative Risk Analysis

2010-09-20T00:14:00.003+02:00

The risk level is referred to as “qualitative” since it is a quick approximation and does not reflect the rigor of a detailed, numerical analysis. The risk level should be high, medium, or low, depending on the severity of impact and the probability of the event occurring.

There are many techniques for performing qualitative risk analysis. Three examples are shown in this section, but there are other techniques as well.

High, Medium, Low Table

Use the following table as a starting point. It helps identify high, medium and low level risks by looking at the probability of the occurrence and the overall impact to your project. For instance, a highly likely / high impact event is obviously a high risk. Likewise an event that has a low impact to your project, and has a low likelihood of occurrence anyway, is obviously a low risk. The other combinations fall somewhere within these two extremes. However, each event must be evaluated individually. If you have an event that is not likely to occur, but the impact, if it occurred, would be devastating (i.e. someone could get killed), you would still want to consider it a high risk and put together a Risk Management Plan accordingly.

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

High, Medium, Low Color Chart

You can also represent these nine simple risk combinations in a table as follows:

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

The green boxes represent a combination of probability and impact that you may safely be able to ignore. The red boxes represent combinations that need to be managed. The yellow boxes represent combinations that should be evaluated further individually.

Risk Probability Table

You can allow for more precision by increasing the number of options available for the probability of the risk. For instance, you could create a five-part scale for the probability of risk as follows.

Probability	Low Impact	Medium Impact	High Impact
Hardly likely (<>	Low Risk	Low Risk	Low Risk
Not likely (<>	Low Risk	Low Risk	Medium Risk
Might or might not happen (35% - 65%)	Low Risk	Medium Risk	Medium / High Risk
Likely (>65%)	Low Risk	Medium / High Risk	High Risk
Highly likely (>90%)	Low Risk	Medium / High Risk	High Risk

Instead of a simple low, medium, high impact, you can be more elaborate. For instance, you could again develop a five-part scale as follows (this scale applies to each risk):

low (or no) impact in terms of cost and schedule
a potential 2%-4% impact in terms of cost or schedule
a potential 5%-7% impact to budget or schedule
a potential 8%-10% impact to budget or schedule
high, potential of over 10% impact to budget or schedule

After you create a scale like the one above, you would still need to determine how to analyze the information. For instance, you may decide that a scale level 1 or 2 can be ignored, while a scale level of 4 or 5 should be managed. The level 3 would represent risks that need to be evaluated individually.

Knowing the Informal Leader in your Project Team

2010-09-12T23:09:00.005+02:00

Project managers are typically assigned project teams that consist of individuals from the Business, HR, Finance, Real Estate, and Technologies (if not a tech led project). These individuals either volunteered or were volunteered to work on the team.

Six Sigma, PMP, Prince 2, and other project methodologies touch upon change management but don't focus on important aspects of group dynamics and leadership.

Did you know that teams go through the Tuckman’s Model of Group Development?

You may recognize it as the Forming, Storming, Norming, Performing, and Adjourning of groups. It’s important to be aware of these stages of group evolution because I’ve found that within these stages an informal leader can emerge.

Why does it matter if there’s an informal leader in your group?

Before answering the question, I would like to explain the difference between a formal and informal leader.

A formal leader is an individual whose job is to be the leader of the group (e.g., the Project Manager is automatically the team leader). Organization authorizes role.

An informal leader is an individual who does not have official authority over the team but is being followed by the group members. (e.g., when one finds that the team is following one particular team-member instead of you). Team authorizes role.

It’s important to identify the existence of an informal leader because that individual has the informal power and authority to either support your efforts or completely undermine them.

Informal leaders emerge when the team does not support/believe in your leadership. Below are some tips that have helped me as I progressed from Project Manager to Portfolio level Manager.

Tips to help minimize the power shift to an informal leader:

Ensure you know your leadership style and adopt according to group needs
Prior to kick-off meeting, meet with each individual team-member (even if virtual) and understand the WIIFM (What’s In It For Me) factor
Become familiar with Tuckman’s Model of Group Development
Leverage Myers-Briggs to understand how the team will work together (I recommend this be done as a team and part of kick-off meeting or early stages of team formation)
When hosting meetings listen and observe group for signs of power shift within team

Tips on working with an existing informal leader

Build a strong relationship with individual and understand motivation/outcome from project experience
Obtain feedback from team regarding your leadership style (e.g., Start, Stop, Continue). Leverage data to make adjustments
Conduct a team building exercise where you’re able to instill loyalty and trust in team members
Meet with team members one on one regularly to form a stronger individual relationship, particularly the individuals that are closer to informal leader

Hope this helps. Let me know your thoughts.

Introducing Project Management Techniques on a Project Team

2010-09-12T22:32:00.001+02:00

Project management presents a bigger challenge than just telling everyone on the team to do things a certain way. People who are not used to working within a formal structure and framework can sometimes rebel when they are asked to do it for the first time. These people will first tend to get negative and view the new processes a bunch of overhead, before they start to grudgingly see the value.

If you were trying to implement a project management discipline throughout your entire organization, the job would be much more complex and time-consuming. In that kind of an initiative, you are trying to perform a culture change to project managers, team members, functional managers and clients. When you implement project management processes on one project team, the challenge is much more contained and within your control. On the other hand, the benefits are obviously more limited as well. First, the value that you are providing is limited to your immediate project team. You will also have to create some of the processes and templates your team will use, rather than having a consistent set that your entire organization uses. When your entire organization is moving in the same direction, you will really start to see the overall value that good project management processes can provide.

To help you be successful, I recommend you look at five areas.

Leadership

As the project manager, you are the primary person to lead this change. You set the priorities and you set the tone for how the project is run. If you make sure to define and plan the project well, and then execute and control the project using good techniques, the other members of the team should follow your lead. But, if project team members see that you are not communicating well, and if they see you accept new scope requirements on your own, or if they see confusion on who is doing what, they will obviously question what they are doing. Don’t let that happen to you. Talk the talk and walk the walk.

Project Management Deliverables

You cannot successfully introduce good project management discipline without implementing a set of processes that everyone can see and understand. This starts off with the planning processes. With a large project, it should be understood that you need a Project Definition and a workplan. You also need to have a process for managing issues, scope, risk, communication etc. These don’t have to be long, tedious procedures, but they have to be at a level where people understand what is expected of them and how the project management processes work.

Project Management Advocate

Try to find someone on the team that can be an inside partner. The team will accept the new processes much more quickly if there is another team member who is also on your side. This person should be a senior individual whom the rest of the team respects. They don’t have to be a cheerleader, but they will set a good example and encourage the rest of the team to go along with the work processes that have been established for the entire team.

Communication

You should make sure that the team is aware of what you are doing and why. Explain to them the perceived value and benefit to the project. This is not a one-time message, but one that should be repeated over and over. This type of communication can take many shapes over time. For instance, you can catch someone doing something right regarding the project management procedures, and praise them for their effort. You can also track and publicize how the team is doing in terms of meeting commitments for schedule, cost and quality. It is very difficult to introduce a culture change without a frequent, ongoing and consistent message.

Training / Awareness

Lastly, after you have dealt successfully with the people dynamics and the required processes, you should make sure that no one has difficulty because of a skills problem. If your project were long enough, you would expect to receive a positive return on your training investment. You should think about providing short awareness training to the entire team, and then sending your team leaders or other project managers to more formal project management training.

Summary

There are some advantages and disadvantage associated with trying to implement formal project management processes on a project team. In general, the successful implementation is within your control. If your project is large enough, you should easily see the value and you will have a chance to integrate project management processes successfully before the project finishes.

Your Organization Culture Influences Your Project Management Success

2010-09-04T19:38:00.003+02:00

It should come as no shock to learn that some organizations are better than others at managing projects. There are probably no organizations that have a 100% success rate, and hopefully none have a 0% success rate. However, some organizations definitely perform at a higher level than others.

Have you ever thought about the factors that account for these differences in success rates? One possibility is that the people in some organizations are just smarter than others. However, think about that statement. Do you really think differences in project success rates are a matter of higher intelligence? Probably not. On the other hand, it may be true that some organizations do a better job training their project managers, so they may be more skilled and knowledgeable in the project management discipline. The way your organization deals with training is just one aspect of your overall organizational culture.

There are a number of organizational factors that influence your ability to deliver projects successfully. Here, you will look at two of them – your organization culture and your organization structure.

Culture Has a Huge Impact on Your Success Rate

Your organization’s culture has a lot to do with the success rate of your projects. This goes for projects all through your organization, not just you or one particular project.

The term “culture” generally means “how we do things around here.” Imagine someone asked you how successfully your organization delivers projects. If you say “we’re pretty poor at delivering projects,”you are voicing a perception of one aspect of your culture.

There are a number of areas where culture comes into play on projects.

Process orientation
Many organizations have good processes in place, and people generally follow them. This is perhaps the biggest single factor in overall project success. If your organization follows a good, scalable project management process, you are more likely to be consistently successful on your projects. This means that the entire project team generally knows how to create and follow a workplan and can use standard processes to effectively handle risk, scope change and issues.

Governance
Many organizations have processes in place, but no one follows them. This highlights a problem with management governance. In simplistic terms, governance is the management function having to do with making sure people do what they are supposed to do. Typically, if your management structure is engaged and interested in projects, and if they make sure that your project management process is followed, you will tend to be more successful. If every project manager is on his or her own and management support is haphazard, then you will tend to be unsuccessful.

Training
As was mentioned previously, some organizations do a poor job of training project managers. Typically, these types of organizations do a poor job of training in general. If project managers generally do not have the right skills (other than from the school of hard knocks) you will not be successful.

Roles and responsibilities
In successful organizations, people typically know the role they play on projects and what is expected of them. This includes active sponsors, interested clients and engaged management stakeholders. The sponsor, for instance, needs to perform a quality assurance role, as well as be the project champion in his or her organization. If your organization starts projects and leaves the project manager in a leadership vacuum, you are not going to be consistently successful.

Culture plays perhaps the biggest role in whether your organization is successful executing projects. If your organization has difficulty completing projects successfully, you cannot blame the project managers. They are only toiling within a culture that is not supportive of their efforts. Managers, including the head of the organization, need to step up and evaluate the project culture. Until the culture changes, project managers will consistently struggle to be successful.

Your Organization Structure Can Help or Hurt Project Success As Well

To a lesser degree, your organization structure can get in the way of, or help support, the overall success of your projects. This is a lesser problem because, to a certain extent, you can always change your organization structure. In fact, you can change the organization chart frequently, and some companies do just that. Culture, on the other hand, is not easily changed. It can take years for a large organization to develop a culture of excellence (although it does not take nearly as long to fall back into mediocrity).

Some organization structures can definitely impair your ability to deliver projects. First and foremost are organizations where the project team is doing support work. If your project organization does support as well, it usually means that support issues will pop up that take the focus away from the project. A lot of multitasking and thrashing take place as you move from support work to project work to support work. It is usually very difficult to prepare good estimates, and it is difficult to meet your scheduling commitments. You may be forced into this structure if your staff is small.

Your organization structure may also impede the ability to share resources. For instance, if your project team needs a resource with a specific expertise, you may not be able to easily share that person with another functional area. Some of this is also related to your culture. You could ask yourself whether a different organization structure would help. If it would, you may have an organization problem. If it would not help, then your culture is probably not supportive of resource sharing.

Summary

There are a number of organizational factors that support or inhibit the ability of your project managers to be successful. Granted, “culture” is a broad term, but your organizational culture plays the biggest role in whether or not you are generally able to deliver projects successfully. You cannot attack a culture of mediocrity (or a culture of failure) one project at a time. You need to address it in a broad and multi-faceted way. Your organization structure can also help or hinder your success rate. Your organization structure can determine how well you focus on projects and how easy it is to share resources between different organizations. If you attack the broader cultural problems, you will have a positive impact on many of the organizational barriers to success as well.

Fast Tracking

2010-08-27T19:43:00.002+02:00

A Few Techniques to Get a Project Back on Schedule

Fast track means that you look at activities that are normally done in sequence and assign them partially in parallel. For instance, when building a house, the frame cannot be constructed until the foundation is dry. However, if the house is large enough you may have options to fast track by starting to erect the frame on the side of the home where the foundation was poured first. The foundation will harden there first, and might allow you to erect the frame on that side, while the foundation on the far side of the home is still drying. Another way you could fast track would be to start building the walls on the ground while the foundation was drying so that the walls could be erected more quickly when the foundation dries.

Another example involves designing an IT application. Normally you would not start constructing a solution until the design was completed. However, if you were fast-tracking, you would start constructing the solution in areas where you felt the design was pretty solid without waiting for the entire design to be completed.

Fast-tracking always involves risk that could lead to increased cost and some rework later. For instance, in the example of designing and constructing an application, it’s possible that the design might change before it is finalized, and those final changes may result in having to redo some of the work already underway.

A good rule of thumb is that sequential activities can sometimes be fast-tracked by up to 33%. In other words, if you are fast-tracking, you can start the second of two sequential activities when the first activity is 67% complete. There is risk involved; however, this seems to be a level of fast-tracking risk that is normally acceptable.

Implement “Zero Tolerance” Scope Change

Many projects begin to trend over their deadline because they are doing more work than they originally committed to. This is probably the result of poor scope change management. However, if you are at risk of missing your deadline date, the project manager must work with the client and team members to ensure that absolutely no unplanned work is being requested or worked on – even if it is just one hour – without going through proper scope change management procedures. All energy should go into completing the core work that was agreed to and all additional work must be funded incrementally.

Improve Processes

When you look for the cause of the project trending over schedule, you may find that some of the internal work processes could be improved. The project manager should solicit team member feedback and look for ways that are within your team’s internal control to streamline processes. For instance, perhaps you have a daily status meeting that is not providing value and can be scaled back to once per week. You may also find that there are bottlenecks with getting deliverables approved.

If you find that there are delays caused by external processes, try to negotiate changes to the processes going forward – at least on a temporary basis. For example, you may find that activities are being delayed because people need to work on their yearly performance reviews. While these are important, perhaps the timing of completing the reviews can be changed to allow critical project activities to be completed on schedule.

This is a good technique for longer projects since you have a chance to optimize your project processes, see the results and optimize some more. However, it may not make sense for smaller projects. It is hard to do much process improvement on a 30 day project. By the time you would want to make any process improvements the project would probably be over.

Regain Commitments

Sometimes deadlines are missed so often that the team no longer has a commitment to completing their work on time or within budget. This can especially happen if team members consistently miss their deadlines without consequences. Other team members wonder why they need to work hard to meet their deadlines and budget estimates when others are not meeting theirs. When this happens, the project manager should communicate with team members to gain commitments to complete assigned work on schedule. The project manager needs to try to refocus the team to meet the deadlines they are committing to. The project manager should ask each team member for his personal commitment to do what it takes to meet budget and schedule commitments.

It may be that morale on your team is poor, but that your team members are still hitting their deadlines. That may be fine for now, but it will probably not continue. Poor morale will ultimately cause you problems with your schedule. When people have poor morale, it impacts your schedule in a number of ways.

People are not committed to their deadlines.
Even if they are hitting end dates now, chances are that this will not continue if the team has poor morale.
Quality will suffer.
People that have poor morale don’t care as much about the quality of their work and they may start getting sloppy or careless. This may make it seem like they are hitting their deadlines, but there will be more rework later.
They may quit.
When morale is bad, people may start to look for new opportunities. This will cause project problems if the turnover occurs.
They spend too much time complaining.
When people have poor morale they usually like to commiserate with others. You end up having your team spend time complaining and not spending the time that they need to complete the deliverables.

The team will work harder and perform better if they do not spend time complaining and sulking. The project manager should build shared purpose, increase camaraderie and do some fun things to get people excited and happy again. You can see more information on managing a team with poor morale at 8.2.3.P6 Attack a Team Morale Problem on Many Fronts.

Check Discretionary Dependencies

When you map out the relationship between all of the activities you will notice that some of the activities have a firm dependency and others have a soft dependency. That is, in many cases one activity must follow another activity. However, in many cases you will find that certain activities need to be done in a general timeframe and there are a number of potential activities that could be identified as the dependency. The first case is referred to as a mandatory dependency or “hard logic,” and the second case is a discretionary dependency or “soft logic.” It is important to know the difference.

Discretionary dependencies should be checked to see if you can move a discretionary relationship earlier in the schedule. This will result in starting and finishing the dependent activity earlier, which can help you accelerate the overall schedule. Of course, to have an impact, you must identify discretionary activities that are on the critical path or that influence the critical path.

It is also possible that you have some activities that have external dependencies. These dependencies are imposed by people outside of your project or by other projects. These external dependencies should be checked as well since it is possible that they can be changed in a way that will help you proactively manage your project.

Scope Back the Work or Reschedule the Deadline Date

One final option that is usually available is to look at the work remaining and negotiate with the sponsor to remove some of it from the project. If the remaining work is all vital to the solution, this discussion still might need to take place as a last resort. There may be options to complete the project on-time with less that 100% functionality, and then execute a follow-up project to complete the remaining work.

The other alternative of last resort is to request a slippage of your deadline date and see if you can complete the original work requested if you are given more time.

The key point is that you don’t jump to this alternative as soon as you start to trend past your deadline date. You should first try the other multitude of proactive options available to try to get back on schedule. You should only fall back on reducing scope or asking for more time if all the other tools and techniques fail.

Techniques of Scope Change Management

2010-07-13T12:12:00.002+02:00

Make Sure Only the Sponsor Approves Changes - Not Users and Client Managers

A typical problem on a project is that the team does not understand the roles of the sponsor, client and end users in the area of change management. In general, the project sponsor is the person who is funding the project. If the client were embodied in one person, it would be the project sponsor. The sponsor is usually high up in the organization and not easy to see on a day-to-day basis. In most cases, the sponsor designates someone in his organization to make most decisions on a daily basis.

The people that the project team tends to work with most often are normal clients and end users. End users are the people that use the solution that the project is building. The end users are the ones that will generally make requests for changes to deliverables. It doesn’t matter how important a change is to an end user, the end users cannot make scope change decisions and they cannot give your team the approval to make a scope change.

In proper scope change management, the sponsor (or his designee) must give the approval. The end users can request scope changes, but they cannot approve them. The end user cannot allocate additional funding to cover the changes and he cannot know if the project impact is acceptable. If the change is important enough to the sponsor, he will approve it, along with the appropriate budget and duration changes. If the change is not important enough, it will not be approved. However, it will be the sponsor making the decision, not the project manager, client manager, project team or end users.

Don’t Think that Saying ‘Yes’ to Change Requests Shows Good Client Focus

The project manager and project team sometimes think that they are being client-focused by accepting scope change while still trying to deliver the project within the original commitments. However, if the project is delivered late or over budget, it is usually not good enough to point out all the additional work that was included because of this ‘client focus’. The project sponsor and your managers don’t want to hear about it. In most cases, the project will not be seen as successful since it did not deliver as promised within the agreed–upon budget and delivery date.

The sponsor is the primary client representative. Allowing the sponsor (or his designee) to make scope change decisions shows good client focus. If the project team or project manager approves scope changes, he is not showing good client focus from the sponsor’s perspective.

Include Deferred Benefits in the Cost of a Scope Change

The project sponsor cannot make an informed decision on a scope change request without understanding the business value of the change and the impact to the project. Typically the project manager provides information on the impact to the project in terms of effort, cost and duration. A common deficiency in determining the impact, however, is that the estimates do not take into account the cost associated with deferred project benefit.

In other words, your project will result in a benefit to the company. The benefit usually starts immediately after (or soon after) the solution is implemented. If a scope change request results in the project being delayed, the cost of the scope change should include not only the cost of the actual change itself, but also the cost of the delayed benefit.

Look at the following example. Let’s say your project costs $100,000. The business benefit is $5,000 per month in increased revenue (or decreased cost). As the project is progressing, the client makes a change request that will cost $5,000 and add one more month to the project. The change has a payback of $1,000 per month.

You may go to the sponsor with a change request that states that there is a $5,000 cost and a payback in five months at $1,000 per month. However, the part that is missing is the cost associated with implementing one month late. In this case, implementing one month later than planned also costs the company $5,000 in deferred benefits, making the total cost of the scope change request $10,000. The sponsor may or may not still approve the change. However, taking into account the lost value associated with a project delay should be a part of the scope change impact for the sponsor to see and understand.

An Engaged Sponsor Will Often Say ‘No’

One of the neat things about enforcing the discipline of having the sponsor approve scope change requests is that, unless the change is very important, the sponsor will usually say ‘no’. The sponsor is usually someone high in the organization. He normally doesn’t want to hear about requests for small changes. He wants the original project fulfilled within the original commitments for cost, effort and duration. Even though it may be hard for the project manager to say ‘no’, the project sponsor usually doesn’t have any problem saying ‘no’ to the people in sponsor’s own organization.

Hold Everyone Accountable for Scope Management Process

Many scope management processes work well at the project manager level, but get compromised by team members. If the project manager is diligent in enforcing the scope change rules, the client may try to go directly to team members for changes. For instance, when an agreed-upon report is delivered for review, the client may request a second report to provide more clarity. The team member may agree to the work (showing ‘client focus’). The result is that the activity takes too long or resources that could have been applied to other high priority work get absorbed working in an area that is out of scope.

The bottom line is that everyone needs to be held accountable for the scope management process. Team members must understand the process and why it is important. The client must also understand the process and its importance. Don’t consider these procedures to be only of interest to the project manager and the sponsor. Make sure the procedures are communicated to the entire team.

When clients request scope changes directly from team members, bring this to the attention of the client manager or the sponsor. When team members make commitments for work that is out of scope, deal with it promptly. The first time it happens it may be considered a training matter. The next time it might be a performance problem.

Frustration Culture - Your Company's Actions Do Not Live Up to Its Lofty Principles

2010-07-03T16:59:00.002+02:00

Believe it or not, there are many fine companies in the world that have great products and treat their employees well. There are also many companies that are just plain rotten. Of course, most companies fall somewhere in the middle.

One of the reasons that employees don’t like working at their companies is that their companies are not intellectually honest with them. They say one thing and do another thing. They have lofty ideals or principles on paper, but then they do not follow through and actually implement policies and processes to back up their words. This disconnect can happen within a team, within a department, within a division or within an entire organization.

“Frustration Culture”

In a broad sense, the term culture refers to “how we do things around here.” In a narrow sense, culture refers to the formal and informal policies and procedures that define how you do your job. More broadly, culture includes how you relate to your managers, peers and clients. It refers to how people treat each other. When it is all said and done, people who say that they like or don’t like a company are really saying that they do or do not like the culture of that company.

The term “frustration culture” can be used to describe the way employees feel when a company’s actions don’t follow their words because frustration is the most common feeling that people have in those circumstances. Sure, they are angry sometimes and they may not be motivated, but it all stems from a deep frustration with the inconsistencies.

Here is an example to see how this happens.

Employees come first – except when profits are threatened

Consider this case of two consulting companies. Company A has a fine Mission Statement that explains that their people are their number one asset. Without their people, the company would not exist. (In fact, it’s true. Without its people, the consulting company would have no revenue.) However, it appears that people are their number one asset while they are on billable assignments. If you come off an assignment and sit on the bench for a few weeks, you are likely to be let go. Company A also touts their ability to train employees in new skills. However, training is all funded at each local branch. If your branch is behind its profit targets, training is the first area to be cut. Company A also highlights the variety of assignments consultants can receive, which allows the consultant to pick up many skills in a shorter period of time. But, in reality, since all of their assignments are from customers who are looking for specific skills, it seems you can rarely get new work outside of your current skill set.

Now let’s look at consulting Company B. They are in this same business and have many of the same company goals and principles. However, Company B has a reputation for keeping people on the bench for a long time when necessary. When the bench costs are high, they ask employees to work four-day weeks and take a vacation day on the fifth – a much better alternative to employees than a layoff. Company B also has a real commitment to training, even paying to send people to outside classes and paying for certification. Company B also manages outsourced projects on-site which gives them more flexibility to bring in consultants who don’t have a perfect skill match and allow them to build skills in new areas. Employees love working for Company B.

Why is Company A bad?

Both of these companies make money. Both have been around a long time. In fact, Company A may be larger and have more name recognition that Company B. However, based on this look at each company, Company A is an example of a place with a frustration culture. Their problem is that they do not have an honest culture. They say one thing and do another. Their literature talks about their commitment to employees, but that commitment is only an inch deep when company profits are on the line.

Company A needs to get their words aligned with their actions. For instance, instead of saying that employees are most important, they should say that their shareholders are most important. Many companies are aligned that way. Instead of talking about all of the training opportunities available, they should provide rich opportunities for self-study and then stress the importance of consultants taking responsibility for their own skills development. They should also put policies in place for bench time. It would be better to have a stated policy that says if you are thrown off a project for poor performance, you are subject to termination. They should also state up front that everyone is entitled to four weeks of bench time per year (or whatever length is appropriate). That way, if you are on the bench often, you know ahead of time that you are in jeopardy.

Summary

Good companies usually tell you up-front what is important to them and, in fact, try to follow-up on those commitments. They tend to set and manage expectations very well.

On the other hand, some companies can be truly bad to work for. A big reason is that they are not honest with their employees. They are not intellectually dishonest when it comes to matching their written and spoken principles with their actual actions.

If you are an employee or a consultant, remember that a company’s culture reflects “how we do things around here.” A culture is not written in the company newsletter or posted on the wall in short slogans. After you have been with an employer for a while, you start to get a sense for how decisions are made and how people treat each other. That reflects the company culture. If the culture does not line up with the slogans, remember that the culture is what drives decisions, not the slogans. If you continue to believe the slogans instead of the actions, you will start to feel a part of the company’s “frustration culture.” However, if you understand the actual culture and how things work, you can either choose to accept it or go somewhere else.

Managers should honestly evaluate your company’s actions and words. You should also understand your own actions and words. If the words and slogans don’t match up with your actions, then lobby for change. You may have a limited ability to change the entire culture, but you do have an ability to change your own organization. Start the change now if you need to – start in your own organization, then look for ways to move it outward.

Handle Scope Change Requests with Appropriate Discipline

2010-06-28T14:26:00.002+02:00

When a project begins, you must gain agreement with your client on exactly what you are creating. At a high-level, this agreement is reached through the approval of a Project Charter or Project Scope Statement (or equivalent)). At a low-level, the scope is detailed through the approval of the business requirements. Once these two documents are approved, you have enough information to understand scope through the remainder of the project.

However, like death and taxes, change is inevitable. There are two reasons. First, it is almost impossible for anyone to define ahead of time exactly what the final solution should look like, and so the requirements may change as the solution starts to evolve. Second, overall business conditions change over time. Some of this business change will force changes to the project scope in ways that are not known ahead of time.

So, what do you say when the inevitable changes start to come in? If you say yes without understanding the consequences to the project, you increase your chance of failure. If you say no, you may introduce conflict with the client and run the risk of delivering a solution that does not meet the client’s needs.

The better response is to follow a scope change request process. This process should include understanding the business value of making the change, as well as the impact on the project budget and schedule. You then take this information to the project sponsor (or their designate) for an approval decision. Scope change management is really the art of letting the sponsor make the decisions - once they understand all the facts and implications.

As always, you should establish scope change procedures based on the size of the project. For small projects, you don’t need to worry about scope change very much. The project will likely start and end before the business can change much, and most of the requirements are probably fairly well known. The project manager can quickly evaluate a small change request and work with the sponsor to determine if it should be accommodated.

For larger project, scope change is a big deal, and must be managed accordingly. The entire team, including the client, must be sensitized to understand when a scope change request is being made. The request should be documented and sent to the project manager. The change is analyzed and the resulting information regarding the change, the benefit, the cost and the impact of not accepting the change are brought to the attention of the project sponsor. The project sponsor then determines whether to accept the change or not. If they do, then the budget and timeline are changed accordingly. If the change is not approved, it is noted as such and the project continues on its way. The funny thing is, if you let the project sponsor decide on accepting scope changes, they will usually turn the request down. They understand the need to deliver something close, even if it does not meet 100% of their needs, and then refine the solution over time. In fact, the sponsor typically has a lot less patience for scope change requests that the project manager, and this will eliminate the frivolous and marginal scope change requests immediately.

Summary

All projects need to first gain agreement on the scope and the business requirements before scope change management will stick. After that, the key to scope change management is to recognize that it is the process of letting the client make the scope change decisions. The project manager just needs to make sure that the appropriate information is presented so that the sponsor can make an intelligent, fact-based decision. Many project managers do a poor job of managing scope because they don’t want to be seen as offending the client. However, that should not be a part of the equation at all. Instead, the project manager’s job is to make sure the scope change management process runs effectively, and that the project sponsor has the information they need to make the best decision possible on whether the scope change should be accepted.

How to Initiate Projects Successfully

2010-06-09T23:39:00.000+02:00

Did you know that a large percentage of projects are cancelled before they even reach the detailed planning phase? The most common reason is that they have not been properly defined and scoped, and as a result, they lack the sponsorship needed to ensure their success.

Therefore, it's critical that you initiate your projects as quickly and efficiently as possible, by taking these 6 steps:

Step 1: Develop a Business Case

The first step taken when initiating a new project, is the creation of a comprehensive Business Case. A Business Case describes the business problem / opportunity to be addressed by the project and the alternative solutions available. The potential costs and benefits associated with each alternative solution are also defined.

The Business Case becomes the foundation for the project as it fully documents the reasons for creating the project and the key benefits to be delivered. Once produced, the Business Case should be formally endorsed by the Project Sponsor, before funding is allocated to the project. More info...

Step 2: Undertake a Feasibility Study

A Feasibility Study is completed to identify the likelihood of the alternative solutions actually delivering the benefits stated in the Business Case. Based on the results of the Feasibility Study and the Benefits and Costs portrayed in the Business Case, a preferred solution is identified and once again, is approved by the Project Sponsor.

If you can complete a comprehensive Feasibility Study, then you will greatly improve your chances of delivering your project successfully. More info...

Step 3: Establish the Project Charter

Once the problem and solution have been identified, a new project is then defined to deliver the solution. The "Project Charter" is documented, which essentially describes what the project sets out to achieve and the boundaries within which it must achieve it.

The project vision, objectives, scope, deliverables, project organization and an implementation plan are all clearly stated in the Project Charter document. More info...

Step 4: Appoint the Project Team

Now that the project is defined, it is time to appoint the team. The Project Board is established and the Project Manager is recruited to take on responsibility for the project. The Project Manager recruits the Team Leaders and they in turn help recruit project staff. Every team member is assigned a detailed Job Description, defining their role and responsibilities within the project. More info...

Step 5: Set up a Project Office

The Project Office environment is then established, as the physical place of residence for the team for the duration of the project. This environment will provide the premises, equipment, materials, tools and processes required to enable the members of the project team to perform their roles successfully. A checklist is used to ensure that the Project Office has been set up correctly and will continue to support the Project as needed. More info...

Step 6: Perform Review

Once the project has been defined and the team have been appointed, you're ready to perform a project phase review. A Phase Review is completed to ensure that all of the required Initiation activities have been undertaken and to provide formal approval to proceed to the next phase: Project Planning.

And there you have it - 6 steps to initiating projects successfully.

Learn How to Convince Executives of the Value of Project Management

2010-06-02T15:08:00.001+02:00

(Part 1 of 2)

There is no question that a common set of project management processes provides value to an organization. Even if your organization utilizes “light” methodologies, there is still value in implementing a common set of “light” project management processes that everyone can use on similar projects. The exact argument to use for convincing executives of the value of common project management practices is going to be different from company to company because every company has a unique culture and unique problems they face. Each organization is also starting from a different reality and a different set of problems they are trying to resolve.

Is Your Company Feeling Pain Today?

If your organization delivers projects okay today, your arguments would have to focus on how project management would bring improvements in project cycle time, costs and overall quality. However, the argument is easier if you can identify areas where your organization is feeling some pain today. In that case, your executives will be much more open to changes, since they should be more easily able to see the value.

Enter Project Management

The majority of organizations have a spotty reputation for delivering projects within expectations. Characteristics of these organizations include:

Consistently completing projects late, overbudget, or not meeting agreed upon requirements
Weak standard processes and techniques used inconsistently by project managers
Project management is usually applied in a reactive manner and not seen as providing value
The time required to manage projects proactively is not built into the workplan and is considered 'overhead'
Projects are 'successful' in spite of a lack of planning and project management, through heavy stress and overtime work throughout the life cycle

Good project management discipline is the way to overcome these shortcomings. Having good project management skills does not mean you have no problems. It does not mean that risks go away. It does not mean that there are no surprises. The value of good project management is that you have standard processes in place to deal with all of these events.

The Cost of Project Management

Of course, there is also a cost to implementing project management. This cost is at both the organizational level and at the project level. Some of the organizational costs, such as building a Project Management Office, are long-term. The costs at the project level are more short-term and include the one-time costs associated with having to learn new project management techniques and templates.

Ultimately, if the result of project management was that projects would complete more slowly, cost more and have poor quality, it would not make sense to use it. The opposite is true - using sound project management techniques and processes will give you a higher likelihood that your project will be completed on time, within budget and to an acceptable level of quality.

High-Level Value Proposition

Showing the value of project management is difficult because it is hard to isolate the specific benefits versus what “might” have happened if project management was not utilized. One alternative is to look at the various aspects of project management and show the value associated with each component. Project management processes and techniques are used to coordinate resources to achieve predictable results. The value proposition for project management goes something like this:

Implementing a common set of project management processes takes effort and resources. However, the value of project management to the organization is much greater, and includes:

Better expectation-setting though up-front estimating, planning and project definition
Faster execution through the reuse of common processes and templates
Fewer project problems encountered utilizing proactive project management processes
Better organizational decision-making through more effective project communication
Higher client satisfaction and less rework by building a higher quality product the first time

How to Set Goals and Achieve Them

2010-06-02T14:30:00.001+02:00

As a Project Manager, you have too much work to do and not enough time to do it in. With so much going on, you need to be really focused if you want to achieve success. The best way to get focused is to set 3 Project Goals and then work hard to achieve them. Here's how to do it...

Step 1: Identify what's important

In projects, everything is priority . So you need to take time to sit down with your Project Sponsor and identify what it is that is really important to achieve. Ask them this question: "If there were 3 critical things that the project had to deliver, then what would they be?"

The 3 things might be "delivering on time, under budget and to specification". Or it might be producing 3 key deliverables. Or they might be 3 major business benefits.

Step 2: Set them as goals

Then take these 3 important "things" and turn them into project goals. Remember to make your goals SMART - Specific, Measurable, Attainable, Realistic and Timely.

So why only have 3 goals? It's simple. With everything that goes on in your project, you will only ever remember 3 things long term. That's also why you need to keep them short and simple. If you set 5 or more goals, then you'll probably forget them within a week, making them harder to achieve.

Step 3: Communicate them

Print out your new goals and put them on your wall behind by your desk. Then take your team out for lunch and tell them what the 3 goals are and why they are important to achieve.

Then tell your other stakeholders about them, including any contractors, suppliers and business representatives that may be involved with the project. Make sure everyone in the project knows what has to be done and by when. Then you're all "on the same page" and working towards the same goal posts.

Step 4: Set an Action Plan

Having the goals in front of you every day will help, but you need to get serious and create an action plan to achieve them. Revisit your Project Plan and identify all of the tasks that will specifically help you achieve your 3 goals. These tasks are now the "high priority" tasks for the project and together, they form your "Action Plan".

Assign your best resource to these high priority tasks and make sure they have everything they need to achieve them.

Step 5: Keep an Eye on Progress

As a Project Manager, you can't watch everything. So just focus on the high priority tasks in your plan. Track their progress daily. Resolve any issues that arise with them, as quickly as possible. Personally oversee them if you need to. If they slip, then take quick action to bring them back on track. Do everything in your power, to make sure that these high priority tasks are completed on time, so that you can achieve your 3 goals and lead your project to success.

When Your Project "Goes Wrong"

2010-05-16T13:44:00.001+02:00

It was all going swimmingly well and then suddenly out of the blue you've found yourself behind time, over budget with no clear end in site. To get back on track, you need to take these 8 steps...

Stocktake: The first thing you need to do is to work out how far off-track you are. Exactly how many days are you behind schedule and what is that, as a % of the project timeline? Also, how much over budget are you and what is that as a % of the overall budget?
Re-plan: Then review your Project Plan to see if you can make the time back, by changing your task allocations. First, see if you can reassign people to tasks in a smarter way that saves time. Then check out your task dependencies and see if there is a more logical sequence that completes the overall deadline earlier. Make sure you identify the critical path through the plan so that you know which tasks must be completed and which are a nice to have. Then assign your best people to the critical tasks and try and get those done earlier. Any time you can save through re-planning is precious.
BrainStorm: Sit down with your team and go through your revised plan and see if they can come up with new ideas for delivering the project earlier or save on budget. You might be surprised with what they come up with.
De-scope: The easiest way to get back on track by far is to de-scope your project. This means delivering less than you originally intended. List your project deliverables, prioritize them against the project objectives and see if there are any deliverables that you can ask your Project Sponsor to remove from the scope of the project, to help you get back on track. It doesn't mean that these deliverables will never be produced. It's just that they can be done as a separate activity once the project is complete.
Get Support: If your Sponsor won't change the project scope, then ask them for a deadline extension or for more budget so you can assign more resources to finish it on time. Get their buy-in and support by telling them why you're late. Be honest and upfront. Show them that you're willing to do whatever it takes to deliver on time, but you need their support to do it. With their support, anything is possible.
Control Change: You then need to tightly control change so that new features or deliverables aren't added without your approval. Change is common on most projects, so you need to control it to have the best chance of success.
Rally: Then meet with your team and explain why the project is late and how important it is to the business. Get their buy-in to working harder and longer hours to deliver the project on time. Remember that you need everyones understanding, buy-in and hard to work to deliver your project on schedule and under budget.
Communicate: Keep everyone regularly informed of progress . This will keep them focused and motivated to achieve the targets set.

Take a Quick Test to Determine If You Are a Strong Project Manager

2010-05-13T23:49:00.004+02:00

Project management pundits have written extensively about the processes, techniques and best practices associated with managing projects successfully. There is value to reinforcing these messages from the standpoint of different peoples’ experiences and observations. It is interesting to boil down to the most important skills required to manage projects.

If your projects are small, sometimes you can get away with sloppy or loose processes. However, the larger the project gets, the more skills you need to successfully manage your project.

The following questions have been worded in a way that will allow you to answer “yes” or “no,” even though there are shades of gray on some of them as well. Your comfort in using a particular skill, or the lack of using it, doesn’t mean you are bad, but it does point out something in terms of your project management aptitude.

Okay, take out a sheet of paper and look at these ten project management skills and traits.

(Y / N) You don’t plan well because you consider yourself a “do-er” rather than a planner.
Many people consider themselves action oriented. When they are given an assignment, their first tendency is to jump in and solve the problem. The question has a built-in bias, since it implies that “planning” is not “doing”. Still, answer yes or no.
(Y / N) You manage with minimal collaboration and interaction with customers and team members.
This is the classic case of the person who feels more comfortable working alone. Many people are more productive this way. They work by themselves on the project plan, hand out work assignments and validate that the work is done. However, they tend to be uncomfortable with a lot of people interaction.
(Y / N) You tend to make excuses for problems rather than take responsibility.
Some project managers step up and understand they are responsible for most of what goes on within a project. Others prefer not to work at that level. To them, there is always a logical reason why things don’t get done. What is your preference? Do you try to explain the problems away, or do you take responsibility for the good and the bad, and strive to eliminate the causes of problems and failures?
(Y / N) You are an order-taker for your client. Does client-focused behavior to you mean that you take on whatever the client wants?
Or do you invoke scope change processes to manage the changes.
(Y / N) You let problems sit until they become disasters? Let’s face it.
There are many procrastinators around. Do you consider project problems to be nuisances that you hope will go away? Do you focus on problems only after they reach a high-enough threshold that they are impacting the project?
(Y / N) You don’t create a workplan, or you do not keep it up to date.
This is common on many projects. Many project managers go through the exercise of creating a project workplan, but then they never update it, or they abandon it somewhere in the project lifecycle. If they are asked how much work is remaining, they have a vague idea, but cannot quantify the remaining effort.
(Y / N) You would rather deliver poor quality than admit you need more time.
Many projects finish on time and within budget, but do so only at the expense of quality. These project managers believe they will deliver on time, and then fix the problems in production. Are you one of them?
(Y / N) You spring surprises at the last minute rather than manage expectations.
This trait represents either a tendency to be overly optimistic about what can be done in a short time frame, or else a conscious act to hide information and hope things work out. The first situation can be caused by inexperience, but the second instance is where the project manager withholds information as part of a deliberate strategy.
(Y / N) You ignore risks. Some risks can be seen from the start of a project.
Other risks can be viewed later while the project is executing. Many project managers don’t even consider risk management as a part of their project responsibilities. Other managers can identify risk, but then they do nothing about it until it is too late.
(Y / N) You communicate the minimum information required.
It is surprising how many project managers think that communication is one of the drudgeries of the job. Their project team might be making heroic efforts on the project, but when it comes to communicating status they want to do the bare minimum. They also don’t have regular status meetings. If your project requires extensive communication, would you relish the challenge or be frustrated by all the people who want to know what’s going on.

Score yourself

Okay, now lets add up the "yes" answers. There were ten categories total, right? The number grades should be as follows:

“0” - If you did not answer yes to any category, you likely have a good chance of success as a project manager.

“1” – You are not perfect, but not hopeless. Work on the category so that you can answer “no” in the future.

“2” – This is a borderline score. Depending on what the two categories are, you may be able to overcome the weaknesses through additional focus. Work on the two categories in question to turn them around.

More the “2” – If you answered yes to three or more categories, you have work to do on your project management mindset. This doesn’t mean you are a bad person. But, given the categories above, you should question your knowledge of good project management practices, or else your overall motivation for taking on project management work. Perhaps you can focus on these areas for improvement and take the test again in six months.

Summary

All of the categories above are worded to show weak project management practices. Answering “no” to all ten items does not guarantee success. However, answering “yes” on any of them shows an area that will place a project at risk – especially a larger or more complex one.

Cause and Effect Analysis

2010-05-13T22:47:00.016+02:00

This problem-solving technique is a way to analyze complex problems that appear to have many interrelated causes. One of the key aspects of the technique is the use of a cause-and-effect diagram. Because of the appearance of the diagram, this technique is also called a Fishbone Diagram. (Another name you might hear for this technique is an Ishikawa Diagram. This is named for Kaoru Ishikawa, a Japanese professor who first utilized the diagram in 1943.)

Benefits of this technique include:

It allows various categories of causes to be explored.

It encourages creativity through a brainstorming process.

It provides a visual image of the problem and potential categories of causes.

Use the following process to create a Fishbone Diagram:

	Role	Developing a Fishbone Diagram
1	Project Manager, Team Members	Describe the problem Describe the problem on the far right side of the diagram. This may be the actual problem or it may be a symptom – at this point you are not exactly sure.
2	Project Manager, Team Members	Create the “backbone” Draw a long horizontal arrow pointing to the box. This arrow will serve as the backbone from which further major and minor causes will be categorized and related.
3	Project Manager, Team Members	Identify major cause categories and tie along the backbone Identify potential causes and group them into major categories. Examples of major categories include people, processes, material, equipment, environment, etc. The major categories are identified using brainstorming techniques, so at this point you are not worried if there is disagreement about whether a category holds the potential cause or not. Just put them all up. Make sure to leave enough space between the major categories on the diagram so that you can add minor detailed causes in later. Each of these major categories will be explored in more detail.
4	Project Manager, Team Members	Look for more detailed causes for each category Continue to brainstorm the causes by looking at more detailed explanations for each of the major cause categories identified above. Write the more detailed causes on slanted lines that hook up to the appropriate major category lines.
5	Project Manager, Team Members	(Optional) Look for additional causes for the details Sometimes, the detailed causes will have other, more granular causes coming off of them. If so, connect additional lines to the detailed lines. Three levels of detail is usually the practical limit for this diagram.
6	Project Manager, Team Members	Analyze and prioritize the causes When you are done brainstorming major categories and more detailed potential causes, begin analyzing the information you have compiled. Evaluate each major cause and the potential detailed causes associated with it. Remember that the original list was compiled by brainstorming where all ideas are included. Now, you must determine which items seem like they are more likely to be the cause (or one of the causes). Circle the items that are most promising and should be investigated further.
7	Project Manager, Team Members	Determine which areas have the most impact and best chance of success If there is not an obvious consensus on the top areas to investigate, use some sort of voting system to formally narrow down the top choices with the most chance of success.
8	Project Manager, Team Members	Create an action plan for resolving the circled causes. Remember that there may be a number of potential causes that interact together to create the problem. The action plan must account for these interdependencies. If the detailed causes are still complex, or if not enough information is known, they may be assigned to one or more people for further analysis outside of the meeting.

Scale Your Project Management Methodology Based on Project Needs

2010-04-30T15:52:00.000+02:00

When you mention methodology to many project managers, their eyes roll upward as if to say “Oh no, something else to get in the way of getting my project done on time.” The term methodology often has a bad image, maybe partly because the word itself is long and mysterious.

However, all project managers use a methodology. The term just refers to the processes, procedures, templates and practices you use to manage your project. A better question to ask is whether you use a personal methodology based on experience, or a formal methodology that was defined by your company or purchased from a vendor.

Use Formal Processes on Large Projects

One of the reasons why project management methodology is not utilized as effectively as it should be has to do with scalability, or utilizing the right amount of structure and process based on the size of the project. For example, on small projects, you can get by with very reactive project management. You might manage scope loosely, because the chances of receiving a scope change request are small, and the impact to the project is typically just incremental. Many project managers are not very good at managing risk because small to medium sized projects don’t usually have much risk. In many cases, communication with the customer just means telling them when the work is complete.

Those same processes will usually fail miserably on large projects. Let’s say you have 50 people and a five million dollar budget. (In some shops even that is considered small to medium!) You have to manage the project proactively. Issues will arise that are too complex and too numerous to manage by the seat-of-your pants. Scope change on large projects is usually a given. If you aren’t careful, your five million dollar project will turn into ten million by the time it is done. You need to see risks coming and manage them, or your project will be in deep trouble. Communication with your stakeholders needs to be ongoing, multi-faceted and planned ahead of time. In other words, this is the time when you will be glad to have a full-featured project management methodology to rely on.

Apply Less Extensive Processes on Small Projects

Let’s take the other side now - a small project of 200 hours. You create a five-page Project Charter document and schedule. You gather your team and look for project risks. You expect weekly status reports from your team members and, in turn, send weekly updates to your customer. Scope change requests require extensive documentation and approval. Does all of this sound good so far? Well, it shouldn’t. The entire project is only 200 hours and three weeks in duration. You don't need all of these formal processes for this type of small project.

When this scenario happens, project managers see methodology as burdensome, cumbersome and not adding value to their project. Usually that means that the methodology was defined at a level necessary to manage large projects, and has not been appropriately scaled for smaller ones. The project can still be completed successfully under these conditions, but it introduces inefficiencies and frustration. The project costs more than it should and takes more time than it needs to. And remember, there are usually many more small to medium projects in your organization than large ones.

Methodology is Your Friend

As was said up front, the best answer is to apply scalability and common sense to your project management methodology. When a project starts, the project manager and project team need to go through the standard methodology and scale it to the level needed to manage your particular project. If your company went through this exercise already, there may be pre-existing guidelines that you can use based on the project size. The basic philosophy you should follow is “large methodology for large projects – small methodology for small projects.”

Methodology is your friend. It is there to help you be successful on your project. But, keep your friend healthy – not too skinny, not too heavy. Let methodology work for you, not the other way around.

How to Track Your Projects

2010-04-27T18:24:00.001+02:00

It’s a tough challenge; juggling people, equipment, time, money and materials to complete your project on time. To do it successfully, you need to keep an eye on 5 key areas of your project...

1. Time and Cost

Put an hour aside every week to determine if you are likely to complete the project on time. To do this, identify any tasks that are running late and determine whether they are likely to delay the overall project. Then look for ways that you can save time by; finishing tasks earlier, delaying non-critical tasks to after the project has been completed, or gaining approval from your Sponsor to remove tasks altogether.

You also need to review the total spend of the project to date against the original budget set. Identify ways to reduce costs by allocating cheaper resource, reducing the project scope, or boosting the efficiency of your team.

2. Resource Allocation

You need to keep a constant watch on the percentage of time that your team are allocated to tasks. If you have one person allocated to tasks 50% of their time and another 150% of their time, then you may not be working efficiently. Instead, balance workload fairly so that your team are kept busy 80-100% of their time, without being overloaded. If you intend to overload resource, then only do it for a short period of time, to avoid “burnout”.

As you reallocate work among your resources, keep an eye on the overall resource level. It may be that everyone is under-allocated and you can take a person off the project, saving on cost. On the other hand, if everyone is over-allocated then you may need to quickly allocate more resources to the project as soon as possible.

3. Progress and Efficiency

You also need to track the progress and efficiency of your team. ‘Progress’ means the percentage of tasks completed to date. ‘Efficiency’ means the number of tasks completed on time. You need to track these items to ensure that you are progressing according to plan and that your team are working efficiently in completing tasks assigned to them. ProjectManager.com is one of the few online software tools that provides you with progress and efficiency information, as well as the usual project planning and tracking features.

4. Risks, Changes, Issues

Every project encounters risks, changes and issues at some point. It’s often impossible to prevent them from occurring, so the trick is to resolve them as quickly as possible when they do come up. Throughout the project life cycle, you need to watch them closely. For each item raised, set a ‘target resolution date’ and track these dates carefully to make sure that they are adhered to.

5. Project Health

In addition to tracking the project at the micro level, you also need to stand back and take a look at the project from a helicopter level. You need to gain a clear view of the overall project health. You’ve already done most of the work by assessing the time, cost, resources, progress and efficiency of the project. By also taking a summarized view of the project each week, you can lead the project team towards success.

Manage Documentation

2010-04-21T21:10:00.003+02:00

Document management, directory structures and naming conventions are even more important in large projects. Large projects should also look into the following areas.

Assign a document librarian.
Once you establish a document repository for a large project, you will want someone to be responsible for managing it. This is not a difficult job if the project is small to medium-size. However, if your project generates a lot of documents, this could take a lot of time – perhaps even requiring a full-time team member. You will also want to assign a backup for when the primary librarian is out. The librarian can be a role assigned to one or more of the team members. There are a number of activities to the position that can also be filled by a clerical person on projects that require a full-time position. The responsibilities of the librarian are as follows:
- Coordinate activity that is related to the document repository
- Establish, maintain, and enforce document repository standards and monitor them for conformance
- Identify and resolve repository problems
- Monitor and control access and updates to the repository
- Determine when it is necessary to archive old documents in the repository, and perform archive and purge functions

Don’t be afraid to designate a Document Librarian for large projects. This does not have to be a full-time position. It could be a role that only requires 10% of one person’s time. However, if your project generates a lot of documents you certainly need some type of role and processes to ensure that the integrity of your documentation is protected.

Define access rules.
The access rules describe items such as who can review documents and who can update them. Most documents should be accessible for the entire team to read. Some documents may need to be more secure. However, you should also be clear on the documents that team members can update. In general, the rule is that the person(s) who created the document should be the only one that can update it.

If you use a document management tool, these access rules can be established and enforced. Even if you are using ordinary folder structures, you can still establish clear rules. For instance, you could set up a folder for final, approved documents that no one should touch. You can also establish work folders for each team member to store draft documents, as well as project deliverables that are in-progress.

Create a keyword and indexing scheme for searching.
Depending on the technology of your repository, it should be possible to search for documents. The search can usually be performed by document name (making naming standards more important) and/or by keyword. Keywords are descriptive words that are associated with the document so that someone can find it later by a keyword search if he does not know the name or where it is located. These keywords make up the metadata for the document; that is, they provide a means to describe the document itself. The keyword structure should be defined up-front. Examples of a simple document-indexing scheme would include the document title, subject, author or contact person, submission date and a list of keywords. The document would then be able to be found using a search on any of the words associated with that keyword scheme.
Define repository update procedures.
All team members will need full access to any of their own documents that are in-progress. However, the project team needs to decide whether anyone can make updates to other team member’s documents as well. For instance, it might be appropriate for anyone to add documents to the portion of the library that holds final, approved deliverables. On the other hand, you may want to restrict access to these areas, and allow only the librarian to make the final updates. This is one aspect of the update rules that the team should put in place early in the project. Documents are added on an ongoing basis or at least at the end of every major phase.

Determine retention and purging timeframes.
Purging old documents ensures that the information on the repository is relevant. For instance, weekly individual Status Reports may not be needed after three months. On the other hand, the Project Charter document is needed for the life of the project, even if it is 12 months old. At periodic times during the project, the librarian can archive documents that are no longer relevant and purge the documents from the repository.
Determine repository backup and recovery requirements.
If the document repository is not backed up automatically, the project manager needs to put activities on the schedule to ensure that the backup is performed. If your organization already has automated processes that are backing up the repository, make sure that the frequency of the backup is adequate to allow the recovery of the documents to be as up-to-date as possible. The project manager needs to know where the backup is stored and for how long. At least one recoverable backup of the document repository should be sent off-site in case of a disaster.
Hold periodic repository review.
If your project is very large and the document repository is very complicated, it may make sense to perform a scheduled, periodic review of the repository and the overall document management processes. The librarian will be responsible for coordinating this review. The review can check for the following:
- The repository is being properly backed up and purged
- Documentation is being stored in the right place
- Documents are being indexed and categorized properly so that they can be accessed when needed

Improve your Presentation Skills

2010-04-15T01:53:00.003+02:00

At some point in your career, you might have to stand up and present to a room full of people. And when you do, you'll find that it's not as easy as it looks. So to help you do it, read these tips and hints to Improve your Presentation Skills,

Prepare with care

To give a great presentation, you need great preparation. Start, by thinking about your topic and the audience and what they are most interested in. Then list your key points and write down the general structure of the presentation ahead.

If you need to, write down every word that you want to say and memorize it. Experienced presenters don't need to do this. But if you're a little nervous or you're new to presenting, then by writing everything down it will boost your confidence and settle your nerves on the day.

On the day

Take these 5 tips to give a fresh, vibrant presentation:

Get a good nights sleep beforehand. Eat a healthy breakfast and try and free your schedule, so you're more relaxed going into it.
Before you present, spend 15 minutes going over your presentation.
Then concentrate on your breathing for 2 minutes. This focuses your thoughts, relaxes you and gets rid of any nerves.
Remember, the open and close of your presentation are the most important parts. So put in extra effort here, to make it memorable.
If you forget something or make a mistake, then never stop and apologize. Keep going and try and relax. It will soon be forgotten.

Body Language

It's said that 80% of a successful presentation is about body language, and only 20% is about content. So use these top tips to communicate the right message through your body:

Make eye contact with people at all times. Never stare at the ceiling or back of the room as you present, unless the nerves are too much.
Appear confident. Use an open stance, stand tall and proud. Smile and let your personality shine. Don't be overly formal.
Remember that relaxed body language conveys honesty and openness. So walk around a little and make use of props to hold onto.
Vary your voice and use slow, open hand gestures. Never have your hands in your pocket or play with a pen. Move your hands to an open position and then pause for effect.
Speak slowly and carefully, but passionately. If you're enthusiastic about the topic, then your listeners will be as well.

Spark Interaction

Encourage interaction with others during your presentation. By having others talk for a few seconds, it takes the focus off you temporarily, to let you clear your head and focus on the key points ahead. Another trick to clear your head is to pause while your team are reading a slide or considering key points you've just mentioned.

Remember, public speaking is one of the hardest things to master. But if you prepare carefully, take it slowly on the day and are enthusiastic about it, then you will deliver a powerful presentation to your colleagues.

The Essential Steps to Managing Projects

2010-04-15T01:50:00.002+02:00

There is so much to learn to become a great project manager. You have to juggle time, money, people, equipment and materials. To do it all, some people feel like they have to be a miracle worker! But it's not the case. Just take these essential steps...

Initiate Carefully

When you start your project, wind it up slowly. Define the process by which you're going to manage your project from start to finish. Adopt a Project Life Cycle so you know what you have to do and by when. Then take these steps:

Define the project goals, timeline and schedule
Quantify the amount of resource you need
Specify the project scope and deliverables
Decide if you need to outsource to a supplier
Recruit your team and set up a project office

Plan In Depth

Then identify all of the tasks needed to complete your project. Prioritize them and calculate how long each will take. Create a detailed project schedule, so you know what you have to do, when and how. Then take these steps:

Identify the number of resources you need
Set a budget and plan your expenditure
List the deliverables and set quality targets
Plan your communications so everyone is informed
Decide how you are going to manage risks, changes and issues

Execute Swiftly

The next step is to execute your plan quickly and efficiently. This is the longest phase in the project, so you need to work smart to complete this phase on time. Take these steps:

Record time spent by your team completing tasks
Frequently check your actual vs. planned progress
If you start falling behind, take action or get help
Resolve risks, issues and changes quickly
Keep your team motivated by rewarding good performance

Close and learn

When you've produced all of your deliverables and handed them over to your sponsor or customer, you're ready for closure. Do this by releasing project staff, contractors, suppliers and equipment. Then close your project office and handover documentation. Take the time to identify your lessons learned, as these will be invaluable to your next project.

Are you involved with projects?

2010-04-15T01:47:00.003+02:00

If you are, then consider using a project methodology. It gives you a roadmap for delivering your project, saves you time and improves the quality of your work. So read, on to find out more about...

Using a Project Management Methodology

What is a Methodology?
A methodology is basically "a set of methods or steps that you use to deliver projects". The key point is that you repeat the same steps for every project you undertake, and by doing that you gain efficiencies in your work.

What will it do?
When you use a project methodology it gives you:

A defined set of steps to follow for delivering projects.
A set of templates to help you do things quickly.
A suite of case studies to help you learn.
The ability to customize the methodology provided.
The option to import your existing methodology into it.

What will it not do?
A Methodology is not a silver bullet. It will not fix your projects by itself. And it's fair to say that no methodology "out-of-the-box" will be 100% applicable to every type of project. So you need to customize your methodology to ensure it fits your project environment.

Why use a Methodology?
A methodology will help you by giving you a clear roadmap for achieving project success.

It will tell you and your team what has to be done, how it should be done and by when, to deliver your project on time.

Using a methodology you can:

Startup and plan projects
Monitor time, cost and quality
Control change and scope
Minimize risks and issues
Manage staff and suppliers

You can choose to use the elements of the methodology that are most suitable to each project you undertake. For instance, when managing smaller projects, you can use simple lightweight steps to deliver your project. And when managing large projects, you can use more heavyweight steps to monitor and control every element of your project.

By following the same generic steps for every project you undertake, you'll become more efficient, work smarter and reduce stress. You will also have a clear roadmap ahead, giving you the confidence you need to succeed.

Are Project Managers Overrated?

2010-04-15T01:35:00.002+02:00

Not everyone believes in project managers. Some common complaints include:

They focus on planning and processes, and in the end, don’t produce anything of value.
They speak using business and project management double-talk, and produce only papers, charts, graphs, analysis, etc, to justify why no actual product was going into production.
They have a lack of real experience in the subject area, and they do not know how to actually build a final deliverable.

Is it that bad?

It is difficult to accept the notion that the typical project manager does not have a clue about what he is doing, and in fact cause more harm than benefit. And yet, this is the perspective taken by some.

There are many fine and capable project managers. In fact, most could likely be placed in this category. However, that doesn’t mean that everyone is competent, or that even the capable ones are perfect. That’s one reason (but not the only reason) why there are still projects today that fail, or suffer significant cost and schedule overruns. Being a successful project manager in the past should provide confidence that you will be successful in the future. However, there are no guarantees. Sometimes the manager has been successful in the past, but just does not have enough experience in a particular area to manage a project in that area well.

Some perspective on project management

There is no guarantee that every project will be successful. However, the vast majority of research and information on the subject shows that major work initiatives should be defined, planned and organized as a project. While many cases exist that show successful outcomes based solely on the skills and talents of the project team, the evidence also shows that these instances are in the minority.
Project managers need to focus on results, not processes. However the processes provide the framework to produce the results. Projects that have no processes or poor processes are certainly not going to be successful.
There are good people who have skills or who even specialize in project management. If they apply their skills correctly, the project has a much better chance of being successful than ones that do not apply project management processes.
Some people believe that a project manager must have expertise in the subject matter of the project to be successful. Others believe that a good project manager can be successful on any type of project, regardless of whether they have any subject-matter experience. Our point of view is that subject matter experience is very helpful, but not absolutely vital. It is better to have a skilled project manager with no subject matter experience than a subject matter expert without project management experience.
The project management processes used on a project must be scaled based on the size and complexity of the work itself. If there are too many cumbersome processes in place for a small project, the work will take longer than needed and everyone will be frustrated. Not enough processes for a large project also limits your chance of being successful. However, don’t ever find yourself in a position of using this as your excuse.
Fundamentally, the end deliverables are the reason that the project exists. If you have the best project management processes in place, but you are not delivering your base products, you are not going to be successful.

Summary

The vast amount of study over the past years has shown that project managers do provide value on a project. So, from that perspective I would say that they are not overrated. However, all project managers should make sure they are delivering value, not just executing processes. On the other hand, for those that believe project managers are God's gift to projects, it should be time to reflect on the fact that most of your team members don't feel the same way. If the pedestal is too high, perhaps it should be knocked down a little – maybe to the same level as the rest of the team.

Is your project feasible?

2010-03-31T00:09:00.003+02:00

The best way to find out whether your project is feasible is to complete a Feasibility Study. This process helps you gain confidence that the solution you need to build can be implemented on time and under budget. So here's how to do it in 5 simple steps...

Completing a Feasibility Study

A Feasibility Study needs to be completed as early in the Project Life Cycle as possible. The best time to complete it is when you have identified a range of different alternative solutions and you need to know which solution is the most feasible to implement. Here's how to do it...

Step 1: Research the Business Drivers
In most cases, your project is being driven by a problem in the business. These problems are called "business drivers" and you need to have a clear understanding of what they are, as part of your Feasibility Study.

For instance, the business driver might be that an IT system is outdated and is causing customer complaints, or that two businesses need to merge because of an acquisition. Regardless of the business driver, you need to get to the bottom of it so you fully understand the reasons why the project has been kicked off.

Find out why the business driver is important to the business, and why it's critical that the project delivers a solution to it within a specified timeframe. Then find out what the impact will be to the business, if the project slips.

Step 2: Confirm the Alternative Solutions
Now you have a clear understanding of the business problem that the project addresses, you need to understand the alternative solutions available.

If it's an IT system that is outdated, then your alternative solutions might include redeveloping the existing system, replacing it or merging it with another system.

Only with a clear understanding of the alternative solutions to the business problem, can you progress with the Feasibility Study

Step 3: Determine the Feasibility
You now need to identify the feasibility of each solution. The question to ask of each alternative solution is "can we deliver it on time and under budget?"

To answer this question, you need to use a variety of methods to assess the feasibility of each solution. Here are some examples of ways you can assess feasibility:

Research: Perform online research to see if other companies have implemented the same solutions and how they got on.
Prototyping: Identify the part of the solution that has the highest risk, and then build a sample of it to see if it's possible to create.
Time-boxing: Complete some of the tasks in your project plan and measure how long it took vs. planned. If you delivered it on time, then you know that your planning is quite accurate.

Step 4: Choose a Preferred Solution
With the feasibility of each alternative solution known, the next step is to select a preferred solution to be delivered by your project. Choose the solution that; is most feasible to implement, has the lowest risk, and you have the highest confidence of delivering.

You've now chosen a solution to a known business problem, and you have a high degree of confidence that you can deliver that solution on time and under budget, as part of the project.

Step 5: It's now time to take your chosen solution and reassess its feasibility at a lower level. List all of the tasks that are needed to complete the solution. Then run those tasks by your team to see how long they think it will take to complete them. Add all of the tasks and timeframes to a project plan to see if you can do it all within the project deadline. Then ask your team to identify the highest risk tasks and get them to investigate them further to check that they are achievable. Use the techniques in Step 3 to give you a very high degree of confidence that it's practically achievable. Then document all of the results in a Feasibility Study report.

After completing these 5 steps, get your Feasibility Study approved by your manager so that everyone in the project team has a high degree of confidence that the project can deliver successfully.

There Are a Number of Options for Defining When a Project Actually Starts

2010-03-17T23:57:00.002+01:00

One of the characteristics of a project is that there is a definite start and end date. This seems simple enough until you start to define exactly what these dates mean. There is no universally recommended standard for either date. In many respects, it depends on what the implication of the decision is. You must consider some of the possible options for the start and end date and see what you think makes most sense. The following options can be considered when determining the project tart date.

When the Idea is Generated

Some companies seriously consider this option. The definition you choose can depend on what the implication is and some companies try to focus on the time between when an idea is generated and when the idea is fulfilled though a project. Their concern is that there is too much time to implement good ideas. Tracking a project from the time the original idea was surfaced provides visibility on this total length of time. Unfortunately, it is very difficult to track exactly when an idea surfaced and there are many variables that might cause projects to be delayed while still in the idea stage.

When a Budget is Approved

This definition is a little more concrete than the prior idea. In this definition, an idea has been generated and has made it far enough along that a cost/benefit statement has been prepared. The project has also made it through the prioritization process and an actual budget has been approved. Keep in mind that the budget may have been approved during the prior year’s business planning process. The actual work may not start until the following year. Therefore, this definition again seems to start the clock too early.

When a Project Manager is Assigned

This one is more common. It’s hard to say that a project has started before a project manager is assigned. When the project manager is assigned, the project planning and definition begins and the meat of the project starts.

When the Project Charter is Approved

In some organizations, the project officially starts when the customer approves the Project Charter document. Some companies require an approved Project Charter and schedule before the project team can be allocated. They do this to ensure that the upfront agreement is in place before project work begins.

When the Project Kickoff Meeting is Held

Using this definition, the planning and definition work is considered to be “pre-project” work. All projects start with a formal kickoff meeting between the client and project team. When the kickoff meeting is held, the planning has been completed, the client has approved starting the work, and the project team has been allocated. The kickoff meeting is the time to tell everyone that the project is ready to begin.

Why is the Start Date Important?

To a certain extent, you might think that it doesn’t really matter when the project starts. Having a somewhat undefined start date does not take away from the fact that the work is a project. It’s obvious that the project started at some point, since there was a point when the work was not in progress and a point where the work is in progress. So, at some point the project did in fact “start”.

The reason it is important to know the start date is that there may be consequences and incentives based on how long it takes to complete a project. The following are examples of these consequences.

Project team accountability.
It is hard to hold people accountable for things that are not within their control. For that reason, it makes sense that a project manager is held accountable for the project no earlier than when he or she is assigned. If the project clock starts before he/she is assigned, it is possible that some decisions were made and some resources expended before they were assigned, and therefore they have no control. Likewise, if team members are held accountable for completing a project within budget and on schedule, it is hard to hold them accountable for work and decisions that take place before they are assigned. For that reason, perhaps the project should officially start when the Project Definition and workplan are approved, or after the project kickoff meeting is held.
Process improvement.
Many companies keep track of the total duration of projects and attempt to shorten the average project duration over time. It is important that everyone within the company use a common starting and ending point. Otherwise, the project duration numbers will not be meaningful.
Financial / accounting.
Many projects are considered capital expenditures. Precisely defining when a project starts has consequences in terms of the work that can be capitalized and the work that needs to be expensed.
Comparisons with other companies.
If you compare how long it takes your organization to deliver projects, you want to make sure you have a common definition of start and end dates. If your company considers a project to start when a project manager is assigned and other companies start the clock at the kickoff meeting, it will appear that your company takes longer to deliver projects.

All projects have a start date. But knowing exactly when a project starts is something that companies can define differently. There are a number of events that would be candidates for the start date. If your company does not capture metrics and does not provide incentives based on completing a project on time and within budget, then it doesn’t really matter. However, if there are consequences based on the defined start date, then a company must be careful to make sure that the defined start date drives the proper behavior they are trying to achieve.

The Role of a Project Manager

2010-03-16T09:15:00.004+01:00

A new employee in the company mailroom noticed an older man sitting in the corner, sorting mail, weighing packages, adding postage and doing other simple jobs. He asked his supervisor who the man was.

"That's Joe." the supervisor said. "He has been with the company for 35 years and is getting close to retirement."

"Really?" the new employee replied. "And he's been in the mailroom the whole time?"

"No, he left a number of years ago. But he asked for a transfer back - after spending several years as a project manager."

On the surface, the role of a project manager should be easy to describe. In fact, from a textbook perspective it probably is. But the challenge to understanding project management roles and responsibilities is that they can be different from company to company.

Multiple Roles

Depending on the size and complexity of the project, the project manager may take on other responsibilities in addition to managing the work. For instance, the project manager may assist with gathering business requirements. He may help design a hardware component or write some of the project documentation. Project management is a particular role that a person fills, even if the person who is the project manager is working in other roles as well.

A project manager might manage the project for 45% of his time, perform business analysis for 25%, work on design for 15% and write documentation for 15%. This does not mean that one of the responsibilities of a project manager role is to spend 15% of his time on design. Instead, it just means that the project is not large enough to need a full-time project manager. The project manager spends the rest of his time in other project roles such as business analyst, designer and technical writer.

Depending on the size of your projects and the way your company is organized, a project manager s time may be allocated one of three ways:

A full-time role on a large project.
Project management responsibilities for multiple projects, each of which is less than full time, but the combination of which adds up to a full-time role.
Multiple roles on the same project, each of which requires a certain level of skill and responsibility. On one project, for instance, he may be both a project manager and an analyst.

Responsibilities in a Matrix Organization

The most prevalent organizational structure today is some form of matrix structure. The matrix organization results in the most efficient use of people resources for a company. However, one of the challenges of the matrix organization is that the team members are assigned to the project for work (full time or part time), but the resources report to someone else from a people management standpoint. This can mean that it is harder to get the resources to do the things you need to have done and there is sometimes a sense that team members would rather do what their functional managers request, rather than what the project manager needs. In this type of a structure, there are still a number of proactive things you can do:

Although the team members do not functionally report to the project manager, their work on the project should still be input into their overall performance review. So, you can try to hold people accountable by making sure they understand that you will be providing performance feedback into their review. This should also be reiterated, and agreed to, by the functional managers. If people are not meeting their deadlines, perhaps it is a combination of direct feedback to the person, as well as the feedback from the functional manager, that is needed.
There are project management techniques and processes that should be utilized. First of all, if the availability and performance of the team is in doubt, you should raise this early as a project risk. As part of risk management, you need to put a proactive plan in place to make sure that this risk is addressed.
Make sure your team members are communicating proactively with you. In many cases, it s not the fact that people miss their deadlines that gets the project manager frustrated; it s that they don t give you warning. For instance, if a team member has a deliverable due at the end of the week but he gets pulled into a three-day resolution of a production problem, he needs to let you know so that you can take any appropriate actions. If a team member misses his deadline but does not tell you the reason or warn you ahead of time, he is not managing expectations as he should. By the same token, the project manager needs to communicate proactively as well and make sure the team understands due dates and expectations. The project manager must also communicate proactively with the functional managers and make sure they know when there are resource-sharing issues or people performance issues.

Matrix management involves a complex and delicate balancing act between project managers and functional people managers. The project manager always has limited people management authority in these situations. Yet it is possible to complete your projects successfully. There are many project management processes and techniques that can help. You should also make sure you utilize the project sponsor. After all, it is his project. The sponsor can help you generate the urgency and focus, and the sponsor can also influence the functional managers, if necessary, to make sure that the people are available as needed for the project to be successful.

Tim Berners-Lee: The year open data went worldwide

2010-03-09T23:02:00.001+01:00

At TED2009, Tim Berners-Lee called for "raw data now" -- for governments, scientists and institutions to make their data openly available on the Web. At TED University in 2010, he shows a few of the interesting results when the data gets linked up.

Tim Berners-Lee invented the World Wide Web. He leads the World Wide Web Consortium, overseeing the Web's standards and development.

In the 1980s, scientists at CERN were asking themselves how massive, complex, collaborative projects -- like the fledgling LHC -- could be orchestrated and tracked. Tim Berners-Lee, then a contractor, answered by inventing the World Wide Web. This global system of hypertext documents, linked through the Internet, brought about a massive cultural shift ushered in by the new tech and content it made possible: AOL, eBay, Wikipedia, TED.com...

Berners-Lee is now director of the World Wide Web Consortium (W3C), which maintains standards for the Web and continues to refine its design. Recently he has envisioned a "Semantic Web" -- an evolved version of the same system that recognizes the meaning of the information it carries. He is also a senior researcher at MIT's Computer Science and AI Lab.

Social Media Revolution

2010-02-27T16:36:00.001+01:00

Social Media Revolution: Is social media a fad?
Or is it the biggest shift since the Industrial Revolution? This video details out social media facts and figures that are hard to ignore. This video is produced by the author of Socialnomics.

Manage Change

2010-02-25T11:31:00.004+01:00

It is said that the only constant in the world is change . You can make perfect plans, but they cannot account for every potential change that may occur. The longer your project, the more likely you will be dealing with changes. This is one reason why the TenStep process understands that the initial definition and planning processes do not have to be perfect. You and your team need to do the best job you can given what you know at the time. That is good enough. After that you need to manage the changes.

There are a number of aspects of change that can occur on a project.

Scope changes
Configuration changes
General changes (non-scope, non-configuration)

On most projects, the most important aspect of change is scope change management.

Scope Change

Scope is the term used to describe the totality of the work and the overall boundaries of the project. Scope is used to define what the project will deliver and what it will not deliver. For larger projects, it can include the major deliverables that are created, the affected organizations, the transactions impacted, the data types included, etc.

If you look at the reasons that projects fail, it is usually the result of two problems. Either the team did not spend enough time defining the work and / or there was a lack of scope management. Even if the project manager did a good job of defining scope, the hard part comes in having to manage the project within that agreed-upon scope.

The purpose of scope change management is to protect the viability of the approved Project Charter and the approved business requirements. In other words, the Project Charter defines the overall scope of the project, and the business requirements define the deliverables in detail. The project team committed to a deadline and budget based on this high-level and detailed scope definition. If the deliverables change during the project (and usually this means that the client wants additional items), the estimates for cost, effort and duration may no longer be valid. If the sponsor agrees to include the new work into the project scope, the project manager has the right to expect that the current budget and deadline will be modified (usually increased) to reflect this additional work. This new estimated cost, effort and duration now become the approved target.

Sometimes the project manager thinks that scope management means having to tell the client no . That makes the project manager nervous and uncomfortable.

However, the good news is that managing scope is all about getting the
sponsor to make the decisions that will result in changes to project scope.

This is very important. Few clients can see and express every requirement up-front. Therefore, there are usually changes that need to be introduced during the project. These changes may be very necessary for the solution and there may be valid business reasons why they should be included. The project manager and project team must recognize when these changes are requested. Then they must follow a predefined scope change process. This process ultimately brings the appropriate information to the project sponsor and allows the sponsor to decide if the modification should be approved based on the business value and the impact to the project in terms of cost and schedule.

Configuration Change

Configuration management is the term given to the identification, tracking and managing of all the assets of a project or the characteristics (metadata) of the assets. In some organizations this process is more narrowly defined to mean only the management of the physical assets.

General Change

Your project may experience changes that do not necessarily fall under scope change management or configuration management. These changes can be grouped into a general change management category. For instance, let s say one of your team members leave and needs to be replaced. This would not be an example of scope change and it is not a configuration change. It is a general change. In this case, you may need to document the fact that a resource change occurred, determine the impact of the change, put a plan in place to manage the change, etc. In many respects, you will follow a similar process to that of a scope change request, although this change, and the impact on your project, is not the result of a scope change request.

One of the key differences between general change management and scope change management is that you expect that is a scope change is approved you will change your budget and schedule to accommodate the change. You should not have that same expectation for non-scope related changes. For example, in the example above when a team member needed to be replaced, there was definitively a change, and there will probably be an impact on the project. However, there is no expectation that this change will result in an approved schedule or budget change. In fact, there may be an impact on schedule and budget. However, there should not be an automatic expectation that a schedule or budget change would be granted.

Ten Techniques for Managing Virtual Teams

2010-02-19T11:26:00.002+01:00

Most everyone works in a team environment. It has always been understood that the most effective teams are those located together. In fact, many managers decide to co-locate their team after reorganization, even though the constant churn of people moving from place to place is seen by others as unproductive.

Against this backdrop is a global phenomenon that is driving team staffing in the other direction. The Internet, faster and more reliable communication, and collaborative tools are allowing people to come together on teams that are no longer co-located. In fact, the whole concept of globalization is pushing work all over the globe, with independent people and teams working anywhere and everywhere.

These groups are sometimes referred to as virtual teams. They are real teams and they fit a classic definition of teams in terms of working together to achieve a common set of objectives. However, they are referred to as virtual mostly because they do not communicate and interact in a traditional face-to-face manner.

There are some special techniques that can be used to manage these virtual teams.

Establish team objectives. The team members need to know and understand what it is that they are doing together. If each person only understands their own role and their own work, they will always just be individual contributors.

Remind everyone they are a team. If the team members think they are all working independently, they will act independent. If they know they are part of a team working on common objectives and deliverables, they will tend to feel better about their work and be more active in their collaboration with other team members.

Establish ground rules. Even though the team members may be remote, they still need to exhibit a common and acceptable set of behaviors. In fact, it is probably more important for virtual teams. These ground rules include setting the hours when the team members are expected to be working, establishing lunch times, determining which meetings are mandatory (in-person, web or phone), setting expectations for communication turnaround times, etc.

Obtain the right technology. I suppose there have always been virtual teams. However, this trend has accelerated in the past few years. The technology is there to support virtual teams - there is really no reason to be without it. This includes fast access to the Internet, audio conferencing, videocams, collaborative software, shared directories, etc.

Look for opportunities to socialize. Team members located together have opportunities to socialize throughout the day. Virtual teams don t usually have this same opportunity to interact with each other, so it is more important for the project manager to look for ways they can bond. This might include getting everyone together one time in a face-to-face setting perhaps a Project Kickoff meeting.
Be sensitive to cultural difference. It is possible that your virtual team all thinks and acts the same way. However, more and more virtual teams consist of people from multiple countries and multiple cultures. If you are the project manager on this type of team, make sure you have some appreciation for the differences in how people work and how they behave.

Communicate, communicate, communicate. The project manager needs to be extra proactive in his communication to make sure everyone understands what is expected. People can start to feel isolated if they do not receive regular communication. It is hard enough to keep everyone informed on a regular project. The communication lines on a virtual team must be opened up especially wide. The project manager can provide this steady stream of communication.

Adjust and compromise on time differences. The project manager needs to recognize that what is convenient for the project manager is not always convenient to the team members. I was on a project team at a large global company where the manager insisted that team meetings start at 9:00 am. That was convenient to him but resulted in hard feeling from people in other locations that needed to stay very late for these meetings.
Be extra diligent in workload management. The project manager needs to be very precise in assigning work to the virtual team and he needs to ensure that work is completed on time.

Give people shorter assignments. This is not the time to give people long assignments and hope that they are completed by the deadline. Instead of assigning a six-week activity, for instance, the project manager should assign the work in three two-week activities. In the former case, he would not know for sure if the work was done for six weeks. In the later case, he can tell every two weeks if the work is on track.

These techniques and others that you can apply locally will go a long way to making your virtaul team mych more effective.

Stroke of insight: Jill Bolte Taylor

2009-12-21T00:34:00.002+01:00

Neuroanatomist Jill Bolte Taylor had an opportunity few brain scientists would wish for: One morning, she realized she was having a massive stroke. As it happened -- as she felt her brain functions slip away one by one, speech, movement, understanding -- she studied and remembered every moment. This is a powerful story about how our brains define us and connect us to the world and to one another.

History of the Internet

2009-12-13T22:43:00.002+01:00

"History of the Internet" is an animated documentary explaining the inventions from time-sharing to filesharing, from Arpanet to Internet.

5 Impressive Real-Life Google Wave Use Cases

2009-11-18T17:54:00.005+01:00

The Google Wave invite rollout extravaganza started more than a month ago. While in some respects the buzz around Google Wave has started to subside, the term is still constantly one of the top trending topics on Twitter, and new gadgets, extensions, and applications are now starting to appear on a daily basis.

Each day more and more people are opening up their email inbox to find an invite to Google Wave. With that shiny new invite comes the inevitable quest for ideas about to how to put the medium to good use.

Should you happen to be one of those people, we’ve got a number of different resources that you can use to get up to speed with Google Wave. This time around, however, we wanted to look at how people are actually using it now. From process modelling and customer service, to project collaboration, annotation, and gaming, the examples listed here highlight the power of the newborn medium, and in part, showcase what we can expect as the platform matures.

1. SAP Gravity: Modeling within Google Wave
2. Salesforce: Google Wave for Customer Service
3. Mingle: Integrated Project Collaboration
4. Ecomm Conference: Annotating a Live Event
5. Gamers: Google Wave RPGs

source: mashable.com
Author: Jennifer Van Grove

Did You Know 4 0 : The media Landscape

2009-11-04T20:40:00.003+01:00

Karl Fisch, Scott McLeod, and Jeff Brenman have launched a "Do you know" series of videos visualizing data on YouTube since 2007.

They launched the latest version of " Do you know" on September 14th. The video was created together with Xplane and The Economist for their Media Convergence forum in October 2009 and it illustrates the changing media landscape, from the decline in traditional media to the continuous rise of social media and mobile. After some days, the video has become a YouTube Hit with more than 130,000 views.

Web Squared

2009-10-26T12:02:00.001+01:00

Tim O'Reilly and John Battelle explore their vision of where the web is heading: As we approach the six-year mark from the original Web 2.0 thesis, the trends are becoming clearer than ever. Once applications live in the cloud, the key to success will be harnessing network effects so that those applications literally get better the more people use them. But that's just the beginning. Today we see that applications are being driven by sensors, not just by people typing on keyboards. They are becoming platforms for collective action, not just collective intelligence. The "data shadows" that people and things leave in cyberspace are becoming richer and deeper, and are being exploited in new ways. All this is adding up to something profound and different. When web meets world, we get Web Squared.

10 Golden Rules of Social Media

2009-10-22T19:31:00.004+02:00

10 Golden Rules of Social Media to embrace, debate, pass around and refine.

1. Respect the Spirit of the ‘Net. Since 1995, I’ve been writing about and talking about what I call the “Spirit of the ‘Net.” The Internet was not meant for marketing and selling but for communication and connection to people and information. Understanding this, even today, can flip your marketing and selling strategy on its head, but you’ll have far more success respecting the spirit of the ‘Net, rather than throwing money at hard-sell tactics.

2. Listen. In the ’90s, the Golden Rule of posting to a Usenet Newsgroup or other online community was to listen first before speaking. Listening thoughtfully gives you a better sense of not only what people are saying but also how they are feeling. In virtual spaces where there are no visual cues, good listening skills become a powerful asset. Listening also helps you map out your current social media footprint and measure your marketing campaigns over time. The key to successful social media marketing is listening.

3. Add Value. Enter any online conversation with the aim of adding value. Before posting a message as a new participant in a forum, ask yourself: How is this providing value to the conversation? To the community? In some circles, talking about your product or service can be considered valuable, but in most, it is unwelcome and intrusive.

4. Respond. From the early days of setting up the first web presences for clients such as Origins and Dr. Atkins, my company outlined the importance of timely responses to any feedback or queries generated from those sites. The burden of response can be great, but it can be lessened by using the right tools and crowdsourcing answers. A quick response is more important than ever, and thanks to search tools, alert apps and other services, it is possible to achieve. Don’t be a dam in a conversation flow.

5. Do Good Things. Back in the ’90s, a mentor and dear friend — Jerry Colonna — talked about “doing well by doing good,” sparking in me the confidence to build a successful business with an underlying mission to help others. Doing good things can really help you to succeed in social media, too. Just do a Google search for Social Media for Social Good to see the power of this movement. This goes beyond adding value online. It means fundamentally changing your business model from a single bottom line — profit — to a triple bottom line — people, planet, profit — and then perpetuating this social responsibility to all you do in business, including online marketing and selling. I’m working with a financial client right now who truly believes in doing good. My client’s messages and conversations around social good are getting much more traction than the regular financial messages.

6. Share the Wealth. When I used to talk about the Internet around the world, one key tenet I repeated almost every time was to share the wealth. “If you’ve got it, share it, spread it around,” I’d say, but I wasn’t only talking about money. I was talking about time, information and knowledge. In social media, sharing is the fuel of the conversation engine.

7. Give Kudos. Social media works when you are generous. There is nothing wrong with self-promotion, but things really take off when you give others praise or a moment in the spotlight. The rise of retweeting — real retweeting, not spammy retweeting — shows how far giving credit to others can go in social spaces.

8. Don’t Spam. And speaking of spam, there is also an ugly surge of spamming in social media, today’s equivalent of unscrupulous email marketers who inundated our email boxes with garbage and left a bad taste in our mouths for email marketing. On Twitter, I’m finding it a daily chore to delete people I’m following who send out spam messages, but I just don’t have the time, interest or bandwidth to tolerate the “Get Lots of Followers on Autopilot” spam.

9. Be Real. Authenticity is the secret ingredient behind any good and valuable social media marketing campaign. If you know your audience, locate them online, listen, add value, respond, refrain from spamming and just be yourself, you’ll have far better and more long-lasting positive results than if you try to be someone — or something — you’re not.

10. Collaborate. Before you dive into social media for marketing and selling, take a look at who is out there and who is doing it well. How can you work with them, instead of trying to muscle your way into the space with all of your dollars? Those will often be dollars wasted because people can feel that push and recoil from the hard sell, blog about your misstep, sign petitions to boycott your company, you name it. If you put your money in places where it can do good while generating goodwill for your brand, you’ll be much more likely to get a positive result from social media.

Social media tools are only that — tools. The real energy, spirit and power of social media is people. We are social media.

source: webworkerdaily.com

Top 10 Strategic Technologies for 2010

2009-10-22T13:08:00.003+02:00

Gartner analysts highlight the top 10 technologies and trends that will be strategic for most organizations in 2010...

Gartner defines a strategic technology as one with the potential for significant impact on the enterprise in the next three years. Factors that denote significant impact include a high potential for disruption to IT or the business, the need for a major dollar investment, or the risk of being late to adopt.

These technologies impact the organization's long-term plans, programs and initiatives. They may be strategic because they have matured to broad market use or because they enable strategic advantage from early adoption.

“Companies should factor the top 10 technologies into their strategic planning process by asking key questions and making deliberate decisions about them during the next two years,” said David Cearley, vice president and distinguished analyst at Gartner. “However, this does not necessarily mean adoption and investment in all of the technologies. They should determine which technologies will help and transform their individual business initiatives.”

The top 10 strategic technologies for 2010 include:

1. Cloud Computing
Cloud computing is a style of computing that characterizes a model in which providers deliver a variety of IT-enabled capabilities to consumers. Cloud-based services can be exploited in a variety of ways to develop an application or a solution. Using cloud resources does not eliminate the costs of IT solutions, but does re-arrange some and reduce others. In addition, consuming cloud services enterprises will increasingly act as cloud providers and deliver application, information or business process services to customers and business partners.

2. Advanced Analytics
Optimization and simulation is using analytical tools and models to maximize business process and decision effectiveness by examining alternative outcomes and scenarios, before, during and after process implementation and execution. This can be viewed as a third step in supporting operational business decisions. Fixed rules and prepared policies gave way to more informed decisions powered by the right information delivered at the right time, whether through customer relationship management (CRM) or enterprise resource planning (ERP) or other applications. The new step is to provide simulation, prediction, optimization and other analytics, not simply information, to empower even more decision flexibility at the time and place of every business process action. The new step looks into the future, predicting what can or will happen.

3. Client Computing
Virtualization is bringing new ways of packaging client computing applications and capabilities. As a result, the choice of a particular PC hardware platform, and eventually the OS platform, becomes less critical. Enterprises should proactively build a five to eight year strategic client computing roadmap outlining an approach to device standards, ownership and support; operating system and application selection, deployment and update; and management and security plans to manage diversity.

4. IT for Green

IT can enable many green initiatives. The use of IT, particularly among the white collar staff, can greatly enhance an enterprise’s green credentials. Common green initiatives include the use of e-documents, reducing travel and teleworking. IT can also provide the analytic tools that others in the enterprise may use to reduce energy consumption in the transportation of goods or other carbon management activities.

5. Reshaping the Data Center

In the past, design principles for data centers were simple: Figure out what you have, estimate growth for 15 to 20 years, then build to suit. Newly-built data centers often opened with huge areas of white floor space, fully powered and backed by a uninterruptible power supply (UPS), water-and air-cooled and mostly empty. However, costs are actually lower if enterprises adopt a pod-based approach to data center construction and expansion. If 9,000 square feet is expected to be needed during the life of a data center, then design the site to support it, but only build what’s needed for five to seven years. Cutting operating expenses, which are a nontrivial part of the overall IT spend for most clients, frees up money to apply to other projects or investments either in IT or in the business itself.

6. Social Computing
Workers do not want two distinct environments to support their work – one for their own work products (whether personal or group) and another for accessing “external” information. Enterprises must focus both on use of social software and social media in the enterprise and participation and integration with externally facing enterprise-sponsored and public communities. Do not ignore the role of the social profile to bring communities together.

7. Security – Activity Monitoring

Traditionally, security has focused on putting up a perimeter fence to keep others out, but it has evolved to monitoring activities and identifying patterns that would have been missed before. Information security professionals face the challenge of detecting malicious activity in a constant stream of discrete events that are usually associated with an authorized user and are generated from multiple network, system and application sources. At the same time, security departments are facing increasing demands for ever-greater log analysis and reporting to support audit requirements. A variety of complimentary (and sometimes overlapping) monitoring and analysis tools help enterprises better detect and investigate suspicious activity – often with real-time alerting or transaction intervention. By understanding the strengths and weaknesses of these tools, enterprises can better understand how to use them to defend the enterprise and meet audit requirements.

8. Flash Memory
Flash memory is not new, but it is moving up to a new tier in the storage echelon. Flash memory is a semiconductor memory device, familiar from its use in USB memory sticks and digital camera cards. It is much faster than rotating disk, but considerably more expensive, however this differential is shrinking. At the rate of price declines, the technology will enjoy more than a 100 percent compound annual growth rate during the new few years and become strategic in many IT areas including consumer devices, entertainment equipment and other embedded IT systems. In addition, it offers a new layer of the storage hierarchy in servers and client computers that has key advantages including space, heat, performance and ruggedness.

9. Virtualization for Availability
Virtualization has been on the list of top strategic technologies in previous years. It is on the list this year because Gartner emphases new elements such as live migration for availability that have longer term implications. Live migration is the movement of a running virtual machine (VM), while its operating system and other software continue to execute as if they remained on the original physical server. This takes place by replicating the state of physical memory between the source and destination VMs, then, at some instant in time, one instruction finishes execution on the source machine and the next instruction begins on the destination machine.

However, if replication of memory continues indefinitely, but execution of instructions remains on the source VM, and then the source VM fails the next instruction would now place on the destination machine. If the destination VM were to fail, just pick a new destination to start the indefinite migration, thus making very high availability possible.

The key value proposition is to displace a variety of separate mechanisms with a single “dial” that can be set to any level of availability from baseline to fault tolerance, all using a common mechanism and permitting the settings to be changed rapidly as needed. Expensive high-reliability hardware, with fail-over cluster software and perhaps even fault-tolerant hardware could be dispensed with, but still meet availability needs. This is key to cutting costs, lowering complexity, as well as increasing agility as needs shift.

10. Mobile Applications
By year-end 2010, 1.2 billion people will carry handsets capable of rich, mobile commerce providing a rich environment for the convergence of mobility and the Web. There are already many thousands of applications for platforms such as the Apple iPhone, in spite of the limited market and need for unique coding. It may take a newer version that is designed to flexibly operate on both full PC and miniature systems, but if the operating system interface and processor architecture were identical, that enabling factor would create a huge turn upwards in mobile application availability.

“This list should be used as a starting point and companies should adjust their list based on their industry, unique business needs and technology adoption mode,” said Carl Claunch, vice president and distinguished analyst at Gartner. “When determining what may be right for each company, the decision may not have anything to do with a particular technology. In other cases, it will be to continue investing in the technology at the current rate. In still other cases, the decision may be to test/pilot or more aggressively adopt/deploy the technology.”

source: ITP Report.com