1. Confirm that the project or phase has met all the requirements of the customer or sponsor.
2. Close procurements.
3. Verify that all deliverables have been validated and accepted.
4. Collect project or phase records.

The correct answer is 2.

Close procurements is the only answer that is not part of the Close Project or Phase process. The remaining answers are components of this process.

Related Courses
Guided PMP Exam Prep
PMP Exam Prep Boot Camp
PMP Renewal Program

Saying no stinks. When you have to make a decision on a project that stops a stakeholder from seeing their new requirement from happening it is hard to do. It is even harder when you have to end a project because it is a bad business decision.

The hardest project I have ever had to manage, and end, was the acquisition and integration of a new company. I worked at a large insurance company, and we acquired a group who had been subcontracting work for us. The work that they were doing was at a much lower cost than what we were able to deliver, and we wanted to capitalize on that. However, we also wanted to bring them into our corporate infrastructure, back office systems, and operational procedures.

As I scoped the project with the new company, we realized that we couldn’t see the efficiencies if we moved them onto our architecture as it was the systems they used that gave the cost benefit. After weeks of trying different ways with the team from the smaller company to calculate a solution that didn’t mean stopping work, we came to the realization that it just wasn’t possible. The numbers didn’t lie and there was no profit.

Telling senior management that there was no way to make that integration profitable was the hardest job I have ever done. Saying no meant that people were out of work, and we had to go an entirely different direction for the service solution. Saying no STUNK, but I knew that it was my job as a project manager to do that for the good of the company.

Oddly enough, it earned me the respect of the people in the organization who were let go. They knew that we had analyzed all of the opportunities, considered every alternative, and came to a conclusion that we didn’t like but had to admit. I don’t keep in touch with many people from the company who I was actually working for—I do keep in touch with the people who were in the acquired company because together we fought for a project that inevitably just couldn’t make it.

Sometimes the best teams you will ever have are the ones who fight the good fight but let go before achieving the goal. It is not a failure if a project never is completed if the right decision is to walk away. Finishing with no benefit is failure.

Related Posts
Crow Tastes Like Crud (or When to Say You’re Sorry)
Reinvent Your Project Management Wheel

Related Courses
Identifying When Things Go Bad-Before They Happen
Project Management Fundamentals
Project Management, Leadership, and Communication

In my last blog I suggested that it is okay to reinvent the wheel. After all, the wheel is not that difficult to invent; it’s the wheel and axle concept that provides the greatest challenge. But wait, I’m getting ahead of myself. Let’s use our Second Life teleport and travel back to the Bronze Age and the invention of the wheel and axle.

The wheel was not a difficult thing to conceive; it’s just a round object that rolls in a given direction. The use of the wheel for practical purposes, however,  was the tricky and difficult part. The “stroke of brilliance was the wheel-and-axle concept”, says David Anthony, a professor of anthropology at Hartwick College. “But then making it was also difficult”.

There are several concepts to the wheel and axle that make it such a complex system: the ends of the axle have to be perfect, as do the holes in the center of the wheels; otherwise there will be too much friction to turn the wheels. Additionally, the axles have to fit to be free to rotate — it cannot fit too tightly or too loosely. Finally, the success of the entire structure is dependent on the size of the axle, or there will be too much friction to support the load. Because of these complexities, the wheel and axel system cannot be developed in phases. It is an all-or-nothing structure.

Let’s take a closer look:

The basic principle to understand the operation of the wheel and axle is work and tension. Let’s see how this fits into our business model with the wheel being business units and the axle representing business processes. We have a clearly defined set of business goals, and we want to complete these goals using the least amount of energy necessary.

When energy is changed from one form to another we say we are doing work.

The actual equation is:

Change in potential energy = Work done = (mass) x (change in height) x (gravity)

The change in energy (work done) relies only on mass (the object), height (the distance accelerated against gravity) and gravity (the strength of the gravity). If we eliminate the change in height, in principle, no work needs to be done to move forward.

Note to self: Don’t carry projects forward by lifting them to great heights against gravity. If I move them in the same direction as the motion, the gravity of the project won’t be working against me.

Oh, but wait… It can’t be that simple. Won’t that create friction, and won’t that friction act horizontally, opposing the motion? True enough, the wheel won’t get rid of friction, but it will reduce it.

Work = force x distance

Reducing the distance will reduce the work. The smaller the axle, the smaller the distance moved by the wheel against the axle, and so the less the work.

Note to self:  the smaller the axle (i.e. the more refined the business process) between the wheels (business units) the less work required to meet my objectives.

So far this all sounds great but won’t the wheel and axle create tension if I continue to move an object forward in the same direction horizontally? Yes, the wheel and axle was really not intended to be used to roll things, but to work like a pulley: to change the direction of the tension. With the pulley system, the force of one section is redirected and the opposite force is applied to the other section.

Note to self: I cannot ignore tension that is created by the forward movement of a business objective. Instead, by redirecting the tension created when moving an object (business goal) by creating an opposing tension (solution), the amount of work is reduced; thereby getting me to my objectives without extending as much energy.

Time to teleport back to this century and learn from our Bronze Age ancestors. Changing the wheel is not difficult. I can continually refine and improve my wheel; however even the best wheel cannot move my business objective forward without a well designed wheel-and-axle concept. It’s a complex concept that cannot be developed in phases as this might create more work and tension. If my business processes are not working, I think that I won’t try to fix them one spoke or principle at a time. I’m going to take the time to look at the overall wheel-and-spoke structure.

So, go ahead and change your wheel all you want, but please leave my axle alone.

Related Posts
Why Being a Change Agent Is Like Being a Swamp Thing
An Introduction to PMI’s Project Management Life Cycle
The Importance of Being Agile

Related Courses
Project Management Fundamentals
Agile Project Management
Leading Complex Projects

1. Task 89 is riskiest.
2. Task 101 is riskiest.
3. Risk cannot be determined based on the given information.
4. Both are equally risky.

The correct answer is 2

One way to determine the riskiness of a task is to look at the float of the task. The formula for float is LST — EST (late start time minus early start time). Task 89 has 13 time units of positive float. Task 101 has 13 time units of negative float. Negative float means that the project is behind schedule, so task 101 is the riskier of the two tasks. If this task is not finished earlier, the project will finish late.

Related Courses
Guided PMP Exam Prep
PMP Exam Prep Boot Camp
PMP Renewal Program

Types of Wheels

Steering wheel – Controls direction of movement but does not contribute to the actual progression of movement. The steering wheel should be used with deliberate, strategic movement. Dry steering, the act of turning while stationary, should be avoided as it generally puts a strain on the steering mechanism and causes undue wear.

Hot wheel – A “tricked out” car and is only a functional version of the real thing. Its intended use is on a track going nowhere but around and around and around at a fast pace; sometimes flying off track, requiring a yellow flag while you get back on track.

Ferris wheel – Also known as an “Observation Wheel” or “Big Wheel”. The Ferris wheel is an impressive landmark that provides suitable entertainment for many. It’s a non-building structure – a system of connected parts used to support a load. The Ferris wheel is not designed for continuous occupancy; there is no forward motion, and it moves in a non-continuous circular movement with designated starts and stops.

Hamster wheel – Okay, maybe now I’m just having a little fun, but I think it’s worth including. The Hamster wheel allows rodents to run in confined space. The run can be so intense that it may result in foot lesions. But fear not, project manager: the lesions scab over quickly and do not prevent the hamster from continuing its run on the wheel.

Wire wheel – Employs the hub-and-spoke concept to provide a smooth rolling motion that reduces friction.

The hub-and-spoke wheel in project management has undergone changes through the years. Below is a list of hub-and-spoke concepts:

Organic – business units are inconsistent in size and may not be directly connected to others

Centralized – traditional organizational chart where business units funnel up to one group or individual

Central hub-and-spoke – multiple business units connect to a central hub through a series of connecting spokes

Multiple hub-and-spoke “Dandelion” – each business unit may have semi autonomy with an over arching tie back to a central group

Holistic Honeycomb – each individual in the organization is social enabled, yet in a consistent, organized pattern

Do you see your project management wheel listed above? Does your wheel roll smoothly reducing friction? If not, go ahead and reinvent the wheel.

After all, it’s not the wheel that is difficult to invent, it’s the wheel and axle concept that provides the greatest challenge…

Related Posts
Why Being a Change Agent Is Like Being a Swamp Thing
An Introduction to PMI’s Project Management Life Cycle
The Importance of Being Agile

Related Courses
Project Management Fundamentals
Agile Project Management
Leading Complex Projects

I know that being a project manager can be hard. Not just the juggle of resources, stakeholder management, impossible timelines, limited budgets, and needing to get herculean efforts out of a team that doesn’t report to you or consider what you need them to do a priority—but it also can be hard because we are identified as the bad guys forcing people to change their job.

Most of us know our jobs. We come to work each day, login, and know that we are doing pretty much the same thing that we have been doing the past few days. We might WANT things to happen better or faster, but we don’t always WANT to be the ones who change to make those better faster things occur.  My Google wisdom says that it takes 66 days to form a new habit. That is, IF you can get the person to even perform the new habit.

As project managers we are the bad guys causing change. We make organizations progress through a new product and new process. Externally you can look at these projects and say, “Wow, those are great and really beneficial for the organization”; internally sometimes it feels like you are the lowest form of swamp life for making people do things that are uncomfortable, new, and different.

Managing the organizational change aspect is a tricky dance of inspiring people to WANT to change and needs to be part of your assigned tasks on the project plan. Determining how to inform and educate is easy, but transforming the behavior and acceptance is much harder. Having a specific plan that involves senior management sponsorship can help. Repeating the benefits of your new product or process early and often (even after release) is also a great way to instigate change. Find champions within your organization and ask them to help support your cause. Early evidence of how faster and better the new product and process is can also be a way to turn the tide of resistance.

One of the most important things to realize is that although you may be seen as the swamp thing at this moment, once there is mainstream acceptance you will be understood as wanting to actually help progress the organization. I’d like to say that this means that the next time you have a new project that requires behavioral changes in the organization that it will be easier… in fact you will always get to be the swamp monster with the rock, but the more your organization changes the smaller that rock you are pushing uphill will become.

“What is the difference between a project and a service?”

To be honest, I haven’t spent much time thinking about this distinction. However, I think that those of us who practice ITIL consulting and training should have good answers to questions such as this.

Here’s how I answered this question.

A project is something that is temporary in nature and results in a new, modified, or retired good or service. In other words, projects result in the modification of something existing or the creation of something new. A project defines a boundary and includes the resources and capabilities required to achieve project milestones and deliver desired results.

A service, on the other hand, is different than a project in several ways. First, a service delivers some value that customers use to achieve outcomes while removing the ownership of specific costs and risks. Thus, a service always has an operational aspect and will often include a collection of requests related to aspects of that service. Services also define a boundary that specifies inputs and outputs as well as the result that the service delivers.

There is a strong relationship between projects and services. A project might be used as the mechanism by which a service is deployed, retired, modified, or updated. Projects often produce one or more changes and/or releases that, in turn, result in the implementation, modification, or retirement of services and aspects of services.

Another fly in the ointment, that sometimes IT organizations do not consider, is that “project management” itself can be defined as a service that the organization offers. In other words, many IT organizations provide value in the form of a service that applies a standard set of processes to project management activities. In these cases, they control the risk and cost often associated with projects in the form of a defined service offering.

While projects and services are not the same thing, there is definitely a relationship. Organizations benefit from a consideration and appropriate structuring of that relationship.

The Project Management Life Cycle

The term “life cycle” is misleading, because it is neither a perpetual circle of events nor is the sequence of events rigidly fixed. There are five stages to the project management life cycle that usually occur in sequence. During large complex projects it is often necessary to return to planning several times. In this case, the project management life cycle can become very complex with multiple repeats of planning and even initiating processes.

Project Life Cycle vs. Project Management Life Cycle

The “project management life cycle” is different from the project life cycle. The project life cycle refers to the development phases that a project can go through. For example:

• Evaluate – Design – Build – Test – Launch
• Design – Code – Test – Train – Release

The phases that a project goes through are determined by the nature of the project. The project life cycle is tailored to suit individual project needs. In contrast, the project management life cycle stays the same for all projects.

Relationship of Project Management Life Cycle to Phases of the Project Life Cycle

This is where things get really confusing. Each phase can be thought of as an independent project that has its own complete project management life cycle. Stages of the project management life cycle, for the design phase of the project life cycle, are illustrated below. The design phase is essentially an independent project that produces a deliverable. This deliverable becomes an input to the coding phase, which in turn can go through the entire project management life cycle.

Back to the Project Management Life Cycle

In order to understand project management according to PMI, it is necessary to understand the boundaries between the project-management-life-cycle stages or process groups. In order to understand the boundaries between the stages, it is necessary to know what management activities (called processes) are included within each of the stages (called process groups).

Knowledge Areas

PMI divides the management processes within each process group into knowledge areas. What are knowledge areas? They are areas of expertise or specialization. Every project needs to have skills and knowledge in each of these areas.

Understanding the Process Groups (Stages of Life Cycle)

Process groups are defined by the activities they include. It is helpful to have a big picture view of where each of the process groups begins and ends.

• Initiation— Initiation begins when someone in an organization has a project idea. The idea may be internally generated or may be the consequence of a contract with outside customers. Initiation is complete when a project charter and preliminary scope statement have been prepared and a project manager has been assigned to the project.A project charter is an outline (with varying degrees of detail) of what the sponsors of the project expect the project to accomplish. It should define constraints and identify the major stakeholders involved. A preliminary scope statement is a detailed look at what exactly the project is expected to deliver. At this point there is little or no discussion of how–just what and why. Initiation ends when there is a project manager and that project manager has been given the authority and direction necessary to begin planning.
• Planning — Planning begins with the outputs of initiation (charter, preliminary scope statement, and project manager). At the end of planning, the entire project has been thought through: what will be done; how; in what order; and at what cost.
• Execution — Execution cannot begin until there is a plan. Executing is the act of doing what it says to do in the plan. It is completed when all the work is completed.
• Controlling — Controlling is the act of making sure that the work being executed complies with the plan. Controlling is complete when the final outputs of the project (deliverables) meet the prescribed quality standards defined in the plan and are accepted by the customer. It ends at the same time as execution.
• Closing — Organizations learn by documenting what was learned — what went right and what went wrong — and making these documents available for reference on future projects. Closing begins when deliverables are accepted. It involves making sure that all the necessary paperwork is completed in terms of contract administration and sign off. It continues until a project archive has been compiled. This archive includes not only a complete set of project records but also a critical review of lessons learned.

The PMBOK uses terminology that can be confusing. Understanding the working definitions of a few fundamental terms makes the PMBOK a much more useful reference tool. The project management life cycle is a fundamental concept of project management according to the PMI. It is not the same as the project life cycle.

A project is defined as a temporary assembly of resources and capabilities designed to create a specific product or achieve a specific objective. Projects establish criteria that, when met, signify completion of the project.

A program, on the other hand, can be thought of as a collection of related projects that are managed in order to meet a related set of objectives. Where projects are temporary in nature and have a defined beginning and end, programs can include operational aspects.

A good example of the difference between a project and a program is the work that accredited training organizations did to update ITIL courseware in the context of the ITIL 2011 refresh.

For the intents and purposes of this discussion, there were 13 courses that were updated based upon the ITIL 2011 refresh. The series of activities to update each of these courses were managed as individual projects. For example, when we updated the ITIL Foundation course, specific start and end dates were established, along with overall project milestones.  Furthermore, resources were allocated for project activities. For each course that was updated, a similar set of activities was performed.

The projects to update all of the courses were related in terms of their overall objectives and the resources required to achieve those objectives. However, there is an ongoing operational aspect in which we constantly validate that the courseware is accurate and  any errors found are corrected. Therefore, the individual projects to update all of the ITIL courses were collectively managed as an overall program, which includes the ongoing operational aspects associated with keeping the courses accurate and up-to-date.

Fundamentally projects and programs help us apply boundaries and control scope. A good project is a boundary that helps to limit activities to only those that contribute to the objective of that project. A good project manager protects that boundary. A program is also a boundary, but it is broader than the boundary of a single project in that a program considers the contribution of many projects to a related set of objectives.

http://www.youtube.com/watch?v=0TNNHi7U_FE

http://www.youtube.com/watch?v=0eUeL3n7fDs&feature=related

I saw them recently at a show and was stunned with how quickly things are changing and how slow I now feel I am moving (I also feel incredibly old, but that could just be because I’ll be forty in two months). Could it be that I am a prehistoric project manager before I hit my prime? I cut my teeth at a traditional project management shop. We planned for months, executed for months, and often lost our energy to ever appropriately close out anything by the time our product was released. From there I moved to a more innovative shop where we had JAD sessions, war rooms, weekly builds and product reviews, and much more opportunity to bend and flex our designs as the product manager sat in the war room (I was, in fact, both project and product manager and so involved way too much). Today my project management efforts are less and less as my role is not to directly manage projects but to oversee others manage this work. I find myself as THAT stakeholder with countless requests for change and finesse on what was originally requested.

The landscape of product development has shifted over the past two decades and even within the past five years. I don’t have the ability to spend months gathering requirements, vetting options, and then making decisions to build a product and take it to market. Today it feels like I have minutes. Companies are getting smarter about how they shop and expect their partners to do more for them at a faster pace than ever.

As I learn more and more about true agile as a concept for getting work done, I honestly am not sure HOW organizations could NOT adopt agile and survive. The only organizations I’ve been able to identify that might not need to be as agile as the rest because their market pressures don’t change as often as everyone else’s are funeral homes, cemetery caretakers, and perhaps plumbers (although with all the new tankless computerized water heaters and stuff I am probably wrong about that one).

Agile allows you to be flexible. It enables you to work smarter and faster. It allows you to try new ideas and approaches and reject them or accept them and move forward with MINIMAL investment. It helps corporations get to market faster, gain true efficiencies, and move at the speed of life as we now know it.

“Going agile” doesn’t mean getting certified or having one person attend a class and declare the organization ready, it means embracing a change to how you do business as a company. Yes, you can start agile in a small area of a corporation but the ramifications will be far reaching, and for it truly to be effective, you can expect to see the entire organization needing to embrace it.

The new PMI-ACP (Project Management Institute Agile Certified Professional) is not a project manager’s certification but a certification for anyone, in any part of a company, who wants to adopt a mentality of how to get work done faster, with closer goals, shorter timelines, and more flexibility to make change. I can’t think of a job in corporate America that couldn’t benefit from that.

So now that I know the importance of being agile, I’m going to start championing for change to our processes and methods to see how we can adopt and be better prepared to move at the speed of life today.