Change Management

Change Control does good things for you and your projects.  It documents who requested the each change, what the cost and benefit was and who approved/disapproved the change. So if you wind up finishing late and over budget, you have documentation of what happened. Most important It also let’s you manage your users, clients and stakeholders and build good relationships while controlling project scope.

Stopping Scope Creep

A manager walks into your cube and says, “You need to add Chinese classes to the project a requirement that you missed when you were building your plan.”

You let the acqusation slide and say, “Oh what did we miss in our plan and the requirements list you signed?”

“Manderin language training for our phone reps, the number of Chinese customers is skyrocketing.  I need you to squeeze it in.”

“Do you need all the reps to learn Manderin? You asked, scribbling on the change request form.”

“No, Just 20 of them.”

“How long a class do you require? I need that for this change request

The sales manager jerked his head up “5 days. But stop writing. This is your change.”

You shook you head, “You’re the one requesting a change that will increase both cost and duration. Not me.”

The sales manager pleaded, “I just want you to squeeze it in right before the reps go live with the new system, Not make a big deal of it.”

You answered, “I can’t just add it without the sponsor’s sign-off, we need to go through  change control.”

“I know the VP will approve it, we discussed it over lunch.  This is a no brainer.”

“Good,   looked at the chang order.  The university will give us a student trainer but for 5 days. its $5,000 which includes materials. Then once he signs this $5000 increase in cost and a 5-day delay in the finish date, we will be good to go.”

What’s important here is:

  • The PM is not evaluating the benefits of the change, he is just quantifying the impact on schedule and cost.
  • He used the stockholders cost and time estimates
  • No president was established about making changes without an approved change request
  • No Conflict with the stakeholder.  PM was just following procedure.

Now let’s look at a project with no change control

No Change Control Process

Let’s consider what can happened if you don’t have a Change Control Process.  A stakeholder boss asks you to squeeze in a requirement.  On the surface, the requirement looks simple and should not take much time.  You do not want to disappoint your boss, so you agree.  You decide to have Janet work on this since she has time before her next task starts.  Janet explains that she is working on another project during her slack time between tasks on your project.  She could not possibly work on this new requirement.  Gosh, that is right. The project team is only being loaned to you. You don’t “own” all their time.

Well maybe Bob could slip this into his schedule. Bob is amenable.  He can start work on the change and try to complete it in the time that will allow you to stay on schedule.  One week later, the day before the due date, Bob comes to you and says he’s sorry but he cannot finish the task.  His manager is pulling him back because Bob has used all the hours his boss agreed to for this project.  

Now you must find someone to finish Bob’s task by tomorrow.  What are you going to do?  The schedule is slipping since Bob is not available to work on the task.  Your brain starts rushing, thinking about who could fill-in for Bob.  Then your thoughts turn to dread.  How are you going to explain the slip to the sponsor?  You accepted the change from your boss without going through the Change Control Process.  Where are you going to get the additional resource to finish Bob’s work without disrupting something else?  What following work is affected by slipping Bob’s task? 

Change Control Process

You know that any change comes with a cost or an effect on the project baseline. To support an additional requirement, a Change Control Processcompany manager or stakeholder must follow the Change Control Process or they must create another project.  Changes and additional requirements add to some aspect of a project; the time, cost, quality, resources, scope, or risks.  If the additional requirement can be handled on a non-critical path task, it may be possible to support the manager’s or stakeholder’s request. Nevertheless, you should follow your Change Control Process and ask the manager to help you complete the appropriate change request form.  You will review the change with the team to assess the effect on the current schedule and other aspects of the project.  The change request and the estimated impact will be presented to the project sponsor for their consideration.  The project sponsor will make the determination if the change is important enough to modify the current, approved project plan and baseline.

Having and following an established project plan and Change Control Process coordinates everyone’s work to achieve successful project completion.  Changes are often necessary and change requires the stakeholders, project manager and the team to follow the Change Control Process to successfully continue the project work and meet the objective.

Project Management Role

Work Breakdown Structure
Dick Billows, PMP
CEO 4PM.com

Let’s talk about the project management role. What do landing people on the moon and cleaning up your department’s supply room have in common? They are both projects. Project management is about producing deliverables, like new payroll software, a bridge over I-95,  reorganizing the file room, hiring a new marketing director, producing a new personnel manual or taking a 20 minute moonwalk.

Organizations need deliverables like these that cannot be produced by an individual as part of their regular job. In fact, many deliverables require work from a number of people working as a team. Larger projects may require the efforts of people from several different departments within the organization. Coordinating all the people, assigning them tasks and integrating their results is a challenging effort. It requires different tools and techniques than those used by a department manager. Organizations discovered this fact when they encountered difficulty producing the deliverables they needed on time and within budget. Modern project management gained many of its tools from the space program, specifically from the Apollo program to land men on the moon.

Today all kinds of organizations use the tools of project management for efforts that take as little as a few days. A project manager, who may have a regular job in addition to managing projects, leads a team of people in producing those deliverables. wbsProjects are a one-time effort. They are unique, which is why there is a special way of managing them. These tools and techniques are detailed in a project management encyclopedia called the Project Management Body of Knowledge (PMBOK)® that is published by the Project Management Institute (PMI)®. It includes hundreds of tools and techniques that project managers and organizations have developed from years of experience. Project managers don’t use all of them on every project. Instead, they learn what each of the tools and techniques does and how to select the right ones for each project.

Let’s say you are managing a very small project. You will use simple techniques to define the scope which is the project’s objective or goal. You must get this information from the project sponsor. They are the manager or executive who wants the project to be done. The scope of a project should be defined as a deliverable, that is a statement of what the project will produce. The scope statement should also include a metric, a measurement that tells everyone how success will be measured.

The next step in the project management process is to gather requirements. That means you identify all the things that have to be done to produce the scope of the project. Then you would write the charter which is a summary of the project’s scope and requirements. You should also identify the risks the project faces, the resources that will be required to deliver the scope, and how changes can be made to the scope and requirements.

After the project charter is approved by the sponsor, you work with the project team, assigning them tasks, estimating the work and duration for those tasks and then developing the project schedule and budget. When the project sponsor approves the schedule and budget, you and team begin to execute the plan. The team members have their task assignments and report their progress to you on a regular basis, preferably each week. From that data, you prepare status reports and deliver them to the project sponsor. You also deal with changes that people request to the project plan and schedule. Your role as the project manager is to analyze each change and make a recommendation to the sponsor about whether or not the change should be implemented.

Finally, when the last of the project deliverables have been produced, you close the project and archive the data. Having archives of past projects provides valuable information that makes managing future projects easier.

You learn all of those skills in our project management basics courses. Take a look at the basics course in your specialty.

Emergency Projects

Dick Billows, PMP

Emergency projects challenge every PM’s professional discipline. When the emergency strike High ranking execs want fast action now… they don’t want thinking, or planning. If you are not moving at high speed… Get out of the way! Everyone else is frantic and if you don’t start responding franticly, they’ll think you don’t care. These hysteria enablers won’t be still until they have a to do list headed, “Start Work NOW!”

So give them the todo list and then use the resulting silence and calm to identify the decision makers who will judge the success of the emergency response. Let them define success then you can start the planing with a quantified deliverable which defines the scope. 

What if people/property are in danger!

If the emergency is in the “Act of God” category (fire, flood, earthquake, tsunami, meteor strike), there will be law, public  safety and political officials all over the place.  They each will have their own goals want to be in charge of saving people and property. You won’t begin work until all the people and property are secure.  But in the meantime, you can plan so once the people and property are secure you can start work with a developed and detailed plan for whatever type of emergency you face.

Marketing/Operational Emergency 

Another type of emergency is affects the organization’s:

  • market positions
  • product competitive positions
  • systems integrity
  • loss of prized human resources 

There are many examples of these emergencies. In one of them a competitor might exclusively acquire a new technology that will allow them to profitably sell your #3 product for 35% less than you do.  Resulting in a potential drop in your revenues of 23%. 

Recovery Project Scope

The initial thinking about the scope of the recovery project is often focused on “getting back to where we were.” In other words, the recovery project should aim to make us just like we were before the emergency.  But a better way to think through the planning is to recognize that we may

Often the best thing to do is take 5 minutes to assemble a todo ir only It doesn’t matter if you are the most experienced PM out there or if you just started your career in this field. There will be times when things don’t go your way and  you have a crisis project. As a matter of fact, if things wouldn’t go wrong from time to time, we would not have an opportunity to learn from our mistakes. However, it is also important to remember that no matter what the situation, a good PM always turns to problem analysis and planning first, that’s good crisis management. Project Planning Main Page

Towards the end of last year, I was reminded of the importance of planning during times of crisis. We had just completed a smaller migration project. This project was a rather routine exercise, as we had done similar projects multiple times before. The objective of the project was to move a number of trading transactions from one book to another in our main trading platform. We had a standard plan for this kind of project, everyone had signed-off on the plan, we had a number of test rounds, and finally, we did the migration in our production system. And then came the crisis. During our initial analysis and throughout the implementation phase, we had overlooked a small, but rather important parameter, and as a result we had produced a little mess in our main general ledger. Needless to say that most of our users had a tendency to panic, and the first thought was to move into action immediately, and to just adjust the ledger manually. This would have taken a whole day, and it would have bound numerous resources.

Crisis Planning

So how do you convince a crowd not to just jump into action, but to first perform an analysis and a planning session? You remind them about the consequences if the quick fix doesn’t work. The reason we had been in this situation was that we overlooked something before; hence, I reminded them that we don’t want to do the same mistake twice. Obviously, not everyone agreed, but most users understood the importance of analyzing the error and planning the response. So we did our analysis and created a simple “project plan”. This was not an endless document, on the contrary, it was an email, but a structured one. The email had the following sections:

  • Objective including a “business case”, which was the result of the error analysis
  • List of Stakeholders
  • Risks & Constraints
  • Procurement (we concluded that we can fix the problem ourselves)
  • A brief WBS
  • Communications Plan

During this “crisis” planning phase we discovered a very simple method of fixing the error, so the fix was truly “quick” and required a lot less time and resources than the original quick fix. Once the fix was implemented, I produced a lessons learned document and adjusted our standard plan for procedures like this. By following the standard project management during a crisis situation, we had forced ourselves to think first and agree on the way forward. In our case, the analysis part revealed a better solution, but even if we would have had to manually correct the error, we would have brought everyone back into the boat.

Requirements Gathering for a Project

One of the key phases on every project is requirements gathering from the users. If the project manager does a bad job gathering the users’ requirements, they’ll get change requests every week for features or deliverables. The users will say things like, “I found some more things that were “missing” from your project plan. If you don’t add them to your plan I will go to my boss.”

These changes add time and costs, make the users unhappy and damage the PM’s credibility. Making changes to a project plan is not a problem. But it is a problem if the necessary changes to the budget and finish date aren’t approved by the project sponsor. The way to avoid this problem is by using good requirements gathering techniques during the project planning phase. Then the user’s change request will be expressed like this, “I want to add to the requirements I gave you during planning. Tell me what the impact is on cost and the completion date.” Good project managers receive this type of change requests. And they are able to handle them so the user is pleased and, as importantly, the sponsor increases the project’s approved budget and duration.  Requirements Gathering Best Practices

Requirements Gathering Examples

Here is the key difference between the two approaches. In the first situation above, the requirements belong to the project manger.  In the second situation, the requirements belong to the user. Let’s look at a simple example to understand what creates that difference.

The goal of the project is to “Reduce Error Rates.” An unskilled project manger would meet with the users and ask what they need to reduce error rates. Then that PM would create a long list of things the users want. The users view the requirements as belonging to the project manager. So they feel free to add to the list each week. It’s like each of the users sat on Santa’s lap and gave him their Christmas wish list.

On the other hand, a skilled project manager would first get the sponsor to define the project scope. It must be stated in measurable terms like, “The error rate on customer orders is less than 1.5%.” Then the PM and the sponsor would break the project scope down into major deliverables. These major deliverables are the responsibility of each of the user managers. An example could be that one of the user managers is accountable for reducing errors in their department from 3% to 1%.

The project manager would meet with each user manager and ask, “What do you need to reduce your departmental error rate to 1.5%?”  One manager might list new systems. Another might need more people. And another might list modifications to the training classes. The project manager would record each manager’s requirements and link them to the project goal of “The error rate on customer orders is less than 1.5%.” In this process, each of the user managers “owns” the requirements they gave to the project manager.  Requirements Gathering by Prototype

[ctct form=”28721″]

Leading Teams: Six Techniques For Success

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com

A highly motivated, problem-solving team is a key reason for every project success. These teams are committed to completing their assignments on time and within budget so the project goal is met. The proven techniques for leading teams to success include:

  • selecting the right team members
  • crafting the right-size assignment for each person
  • accurately estimating hours of work and duration
  • gaining team member commitment
  • receiving status reports
  • giving constructive feedback.

Leading Teams: Techniques for Three Sizes of Projects

The techniques are different for each project, depending on the size and scope. Here are the project size definitions:

Tier 1: Small – they’re done within one department
Tier 2: Cross-functional – they affect multiple departments and cross organizational boundaries
Tier 3: Strategic  – they’re organization-wide programs or projects for clients with strategic impact.

Leading Teams Technique #1: Selecting Team Members

In the selection process, you’re trying to get the best people for your project team. But you’re also gathering information about their work habits and personality so you can craft the right assignment for them.
Tier 1: Small projects: You are usually familiar with the potential team members’ work performance and quality standards when you all work in the same department. During the project planning phase, you need to ask the boss for the people you want on your team. That’s when the boss is focused on the project and can give you hints about the correct assignment for each person.
Tier 2: Cross-functional projects: When you have to borrow your team members froLead Teamsm other departments or organizations, it is more difficult to make sure you get productive team members. If possible, you should interview potential team members to assess their work ethic, problem solving ability and quality standards.
Tier 3: Strategic projects: On large projects for your organization or your clients, you may not be able to select the team members. If personal interviews are possible, you can gather information about potential team members’ experience and work standards. You will use that information to design the right assignments for each person.  If interviews aren’t possible, you will have to make an on-the-spot judgement about the right assignment for each team member. Leading Remote Project Teams

Leading Teams Technique #2: Designing Appropriate Assignments

You must design the assignments so they fit the capabilities and personality type of each team member. You want to give larger/longer assignments to people who have solid technical experience and are skilled problem solvers. They will appreciate the assignment’s challenge. You should give shorter assignments to people who are inexperienced and/or less capable. This will let you easily track their progress and help them when it’s necessary.
Tier 1: Small projects: You usually have flexibility about the duration of assignments. For trainee-level team members or less capable people, you want assignments that are 1 to 3 days long. For the average team member, 5-day assignments are usually the right size. For experienced professionals, you should design assignments that are 2 weeks or longer to give them a challenge and independence.
Tier 2: Cross-functional projects: With people borrowed from other departments, it is often acceptable to talk with their boss about the right-size assignment and the level of challenge you should give them.  If that’s not possible, then you will adjust the complexity and length of the assignment as they work on the task and you learn their capabilities.
Tier 3: Strategic projects: On larger projects with people who are accountable for major deliverables, you need to engage them in the design of their assignments. You must avoid micromanagement of these experienced people who are very capable.  On the other hand, you should give “rookies” assignments that are within their capabilities in terms of time and complexity. Team Micromanagement

Leading Teams Technique #3: Work Packages

You must clearly describe, in measurable terms, the deliverable(s) the team member should produce. And you must document their availability, as approved by their boss.
Tier 1: Small projects: This level of documentation is often skipped on small projects with three or four team members working on a project within a department. On the other hand, giving a simple work pack to each team member avoids confusion about your expectations for their deliverable.
Tier 2: Cross-functional projects & Tier 3: Strategic projects: For larger projects, you should document a work package for each assignment. It will make the assignment clear and document the deliverable you expect the borrowed person to produce. The work package also provides a standard information base for estimating the tasks’ hours of work and identifying their risks. It is best to document the work estimate and give a copy to the borrowed team member’s superior. Team Building Techniques

Leading Teams Technique #4: Estimating Task Work and Duration

A project management best practice is to estimate the required hours of work so you can measure progress during the assignment.
All projects: Regardless of the size of the project, you should engage the team members in the process of estimating the amount of work their assignment will take. The work package is the basis for the estimating effort. You should always estimate the amount of work (50 hours, for example).  You should never estimate just the duration (Oct. 21 through Nov. 7, for example). Estimating the amount of work required for the task provides you with the ability to more accurately track progress and spot problems. Their team member’s availability to do the work (halftime or 2 days a week, for example) is also documented. Team Building

You should also discuss the assignment’s potential risks with the team member and what can be done about them. This helps you avoid, eliminate or mitigate those risks. Finally, the work package should list the task’s required deliverable, the approach to take on the task and the inputs the team member requires to finish their task. Team Building video

Leading Teams Technique #5: Status Reporting

Team members should report status on their tasks every week. This allows you to find problems early so you and the team have an opportunity to fix them before the task or project is late or over budget.
All Projects: Data can come to you by phone, e-mails, a form, template or on “sticky notes.” The important thing is that each week you get the hours of work competed, as of that date, and the estimated hours required to complete the task. No narrative is necessary. You should make status reporting easy so people will do it.  It is a best practice to give all team members updated status data on the entire project.

Leading Teams Technique #6: Giving Feedback

All projects: You must give feedback to team members on a timely basis. People want to be praised for a job well done. Remember that public praise is the most effective. People also need to be told when their performance does not meet your expectations. This should be done in private and include what they can do to improve. You must deliver feedback in a way that encourages people to tell you about problems early, when you and the team can define a solution or a “work around.” Constructive Feedback

It is extremely ineffective for you to get angry with team members who report bad news. This action (or reaction) causes team members to hide problems. Then you are doomed to find out about problems when it’s too late to fix them. Dysfunctional Project Team video

Leading Teams Summary

Use these proven techniques to successfully lead project teams:

  • select the right team member for each task
  • assign the right size task for their capabilities
  • create a work package to define their deliverable
  • involve the team member in estimating the amount of work required and the duration of their task
  • receive weekly status reports from the team members
  • give team members constructive feedback and praise

Matrix Teams

Project Team Culture

You can learn these techniques and enhance your skills for leading teams in our online project management courses and certifications. You begin whenever you wish and control the schedule and pace. You work privately with an expert project manager and have as many phone calls and live video conferences as you wish. Take a look at the courses in your specialty.

Get free articles and videos like this every week

What is Project Leadership? – Video

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com
Dick’s Books on Amazon

What is project leadership? It consists of proven techniques that project managers use to:

  • set standards of behavior and performance
  • motivate the team members to high performance and
  • rally the team members when the project has problems to overcome.

The number one challenge to project leadership is the fact that the project manager has no formal organizational authority over the project team. Another factor that makes project leadership difficult is that project managers are usually technically-oriented people with little experience or skill in motivating others.

Project managers must tailor the interpersonal techniques they use to fit the personality of each team member and stakeholder with whom they work. That’s the only way project managers can make up for their lack of formal authority.  Once they have “typed” the person’s personality and selected the right techniques for dealing with them, they have won half the battle. Here is a video on Team Member Personality Types

Another technique of effective leadership is to apply the best practices in terms of how the project manager trains and treats their project team members. Watch this video of a PM dealing with a situation where a team member has been pulled off the project and assigned elsewhere. In the first video, you see the PM use a technique that does not fit the personality of the team member. The result is complete failure. Then watch an analysis and see the PM do it the right way, using the right technique for the team member. Leading Teams

Communicating with the team member who has a problem

You can learn all of these skills in our online project management basics course. We individually tailor this course for business, IT, construction, healthcare and consulting specialties.

Get free articles and videos like this every week

Stakeholder Management in Four Steps

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com

Stakeholder management began as an effort to identify your project’s stakeholders so you could gather their requirements. This let you avoid requirements that spring up late in a project. These late requirements cost many times what they would have cost early in the planning process. So time spent on stakeholder management has a positive payback.

The new focus in stakeholder management adds to that “requirements orientation” and provides tools for building and maintaining support from your stakeholders. It involves engaging them in the project management process itself. It also includes identifying their project expectations early and managing those expectations so they align with the project’s deliverables.  Stakeholder Main Page

Stakeholder Management in The Real World

If you manage projects in the “real world,” you know that strong stakeholder support for your project is critical in several areas.

First, broad support for your project helps you keep your project team together and avoids losing them to other projects. In reality, every project is competing with the organization’s entire project portfolio for resources.  Your team members will be reassigned to higher priority projects if you have poor stakeholder support and/or unmet stakeholder expectations.

Second, most projects involve implementing changes, whether it’s following new procedures, using new software, or installing new hardware. Those changes have to happen in operating/user departments and they always cause pain and take time. If you lose stakeholder support for your project, implementing those changes in the operating departments will fall behind schedule. They may even be ignored.  Your ability to deliver your project’s scope is negatively impacted if those changes are not implemented.

Third, engaging your stakeholders in the project management process yields significant benefits. As an example, when you involve stakeholders in your risk management process, they are more likely to support and participate in your risk responses. This also helps you gain support with operational areas that are lending you team members. Always keep in mind that you are competing with other projects for those resources. You’re also competing with their “real jobs” and any projects that are launched in their home departments. When you engage the operational area boss(es) from the start of your project, you have a better chance of those resources being available when you need them.stakeholder management

Stakeholder Management in Four Steps

For all these reasons, we recommend this four-step stakeholder management process.

First, during initiation you identify the people and organizational units who will be affected, positively or negatively, by the project. These stakeholders can come from outside the organization as well as the internal players. You’re identifying not only who they are but what interest they have in the project. This includes their “hot button” issues, their project requirements and their potential influence over the project.

Second, during the project planning phase you plan how you will manage your stakeholders. You identify what techniques you will use to meet the needs of each stakeholder and to keep them engaged in the process.

Third, during your execution of the project, you implement the stakeholder management plan. It includes the communication strategies you will use to engage the stakeholders in the project and build their ongoing support.

Fourth, as you execute and control the project, you’re also monitoring the stakeholders and identifying problems and issues.  New requirements or requirements that are not being met are examples of stakeholders’ problems and issues. You must respond to these to maintain their support.

Stakeholder Management Summary

This four-step process may take an hour on a small project or weeks on a large one, depending on the size of the stakeholder group. But it’s a proven fact that active stakeholder management builds a foundation for your project’s success.

You can learn how to successfully manage stakeholders in our online Project Management courses. You’ll work privately with Dick Billows, PMP, an expert project manager. You control the schedule and pace and have as many phone calls and live video conferences as you wish.

During an introductory video conference, you and Dick Billows PMP, will design your program and what you want to learn. You will choose you course and select your case study from business, marketing, construction, healthcare, or consulting options.  Your case study-based assignments that include project plans, schedules and presentations will fit your project specialty.

Project Failure: How To Rescue It

project failureProject failure rates top 70% in some organizations. Why is that? Here is the project management process in theory. First the project manager and sponsor define the scope in crystal clear terms that everyone understands.  Then the project manager and team  “just” execute the scope. What can go wrong? Lots! So much for the theory. Enterprise Project Management Main Page

We all know how projects should be initiated but they often aren’t done the right way. As a result, you, the project manager, must try to rescue these failing projects. In one situation, perhaps someone else did the planning and you are assigned to take over the execution phase. In another situation, perhaps the project is headed for disaster and you have been asked to save it. I hope that this post will help you successfully manage whatever project situation you’re given. Project Failure

Project Failure: How To Rescue It – Step #1

When you take over a  project failure in process, your first and most important task is to understand the project’s scope. If you don’t know where the ship should go, you won’t be able to steer it. Also, if you don’t understand the scope, chances are you are not alone.  The project team, stakeholders and even the project sponsor may not be able to define the scope. If you can’t “uncover” a solid scope statement, it is never to late to write one.  Without a solid scope, you will have a hard time finishing what someone else started. I found it’s very useful to clearly state what is and what is not in the project’s scope. Make sure that at least you and the sponsor are crystal clear about what the project has to deliver. Project Rescue

Project Failure: How To Rescue It – Step #2

Next, you should try to locate the project charter and the stakeholder register. The project charter should tell you why you do what you do and what your boundaries are as a project manager. This is a very important document because you will have to maneuver the project around many obstacles. So you must know what the boundaries are. The stakeholder register is important because it lets you get in touch with the people who are most important to the project. The stakeholders are the people who are affected by the project and have an interest in its success.

Project Failure: How To Rescue It – Step #3

Third, introduce yourself to the major stakeholders and the project team. Make sure all of you have the same understanding of the project scope. Get the project team together and discuss the current status. This is also a good time to go over the project plan with the team. Once you know the scope, it is easier to spot weaknesses in the plan. It’s best if you go over the plan with the project team.

Project Failure: How To Rescue It – Step #4

Last but not least, if you and the team identify a major weakness, you should address it. You don’t have to re-invent the wheel, but you should listen to what the team, the stakeholders and the sponsor want to do differently. Project Catastrophes

Project Failure: How To Rescue It – Summary

Here is the bottom line: don’t shy away from accepting the challenge of rescuing a project failure. I urge you to start with the scope. Your job as the project manager is to keep the big picture in mind. If you have to turn a project around, you will find that most often the project failed because of scope creep or other scope-related issues. If you tackle the scope first, everything else will fall into place.

You can learn how to correctly manage the entire project process in our online project management courses. You’ll work privately with an expert project manager. You control the schedule and pace and have as many phone calls and live video conferences as you wish.

Get free articles and videos like this every week

Requirements by Prototype

Gathering your project’s requirements by using a prototype can be effective because it is very attractive to the users.  Requirements by prototype consists of planning and then developing a sample deliverable for the users to “play with,” review and modify.  Prototyping takes some pressure off the users.  They don’t need to specify all of the requirements up front, without having evidence that they work.  After the team produces the initial project deliverables, the user/client evaluates the prototype and tells the project team about the prototype’s flaws. Then the team goes back to work to fix those issues. They produce another prototype for the user/client to evaluate, and the cycle goes on.

Project managers use prototyping with certain types of projects. It’s most often used in software development where the cost of making changes to the prototype is not too expensive. They also use prototyping in manufacturing, depending on the cost of each iteration. Prototyping can take a great deal of both the user/client’s and the project team’s time, depending on the number of iterations. The arguments in support of prototyping are that it encourages continuous contact between the user/client and the project team. Fans of prototyping say it produces a higher quality result and a shorter development cycle. On the other hand, prototyping can create a situation where the project team works on the effort forever. That’s because the user’s requirements change every time they look at a prototype.    Requirements Gathering Main Page

Prototype vs Iterativerequirements by prototype

The requirements by prototype process is different from iterative development because we’re only asking for the requirements, not a final deliverable.  We start by talking to the user and making a plan. Then we produce the prototype. Ideally, the user would review the prototype, make changes and then we would produce the final deliverable.  In the real world we’d make another prototype for the user to review and modify.  Producing one prototype after another allows us to develop the final deliverable prototype by prototype.  Depending on the deliverable, prototyping can be very expensive and time consuming. But if a user or client wants to pay for this approach, a good project manager can accomodate them.

Prototype vs Waterfall

Using prototypes is very different from the classic waterfall approach where we finalize the whole plan in a lengthy planning effort, and then produce the deliverable. The waterfall approach is cheaper.  But it requires the client or user to commit to exactly what they want during the planning process.   It also limits the changes the client can make once we begin to execute. The prototyping approach allows for changes during each iteration, if the client will bear the cost.

Get more articles and videos each week

What Is a Project

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com

Are you wondering what is a project and what is not? Here is an example of a project:

The manager of the department you work in tells you the people are wasting time getting supplies from the supply room. He wants you to do a project to fix the problem.

Projects have a specific objective (goal). We want to achieve the goal so we have to do the project only once.  If you keep doing the same project over and over, obviously you’re not achieving the results the boss wanted.

What is a Project: Some Examples

The characteristics of all projects are the same. Their size doesn’t matter. All projects have a unique and specific objective. They have a beginning and end date. They often have a specific budget. The expectation is that we do them only once. Here are some examples of projects:

  • opening a new business
  • developing a computer program to process payroll
  • resurfacing a highway
  • opening a new healthcare clinic
  • What is a Projectbuilding an apartment complex.

What is a Project: The Steps

All of the efforts listed above are projects. All of them follow the same general steps:

  1. Project initiation – in this first step, a manager or executive comes up with the idea for the project. They give a project manager and other people an overview of the idea. The initiation process often includes obtaining approval from the organization to spend money on a project. When approval is given, we begin planning.
  2. Project planning – we need to communicate what the project is trying to produce. That’s called the scope and it’s defined by the manager or executive who initiated the project. Next the project manger develops the project plan. It includes a schedule, a budget and the people we need to work on delivering the scope. Larger projects have many stakeholders, the people who are affected by the project. So the plans for larger projects are more extensive. The project manager presents the project plan and schedule to the organization. When it’sapproved, we begin to execute the plan.
  3. Executing the project – most of the time and money on a project is spent during the executing phase. This is where we actually perform all the tasks specified in the project plan. The tasks are the deliverables that the team produces. The project executive or stakeholders review and accept the deliverables. They may also ask for changes. The project manager is monitoring everything that is happening.
  4. Monitoring and controlling – the project manager will monitor actual results and compare them to the plan. He or she will also identify differences (variances) between the two. When there are differences between the plan and the actual results, the project manager works to correct them.
  5. Closing – when the final deliverable has been produced and accepted, the project needs to be closed out. That involves holding a lessons learned meeting. It documents what we did and didn’t do well.  The intent is to have data that is useful on future projects and help avoid making the same mistakes. Archiving data from the project makes future projects easier and more successful.

[ctct form=”28721″]