In earlier articles I have gone through the steps to define the project scope using a Scope Statement. The Project Scope Statement contains the definition of the scope in detail and for IT projects this is typically in the form of an Enterprise Design Document (EDD).

So we have a detailed description of the scope (the design of the software); where do we go from here? We need to break down the project deliverables into progressively smaller components so they are easier to estimate for time and cost. This is also called decomposition and the resulting structure is called Work Breakdown Structure or simply WBS.

In the WBS, the top layer is of general nature and each subsequent layer gets more and more specific until we are left with small units (or packages) that easily can be estimated for time and cost and at the same time provides enough information to proceed with subsequent activities.

At the bottom of the Work Breakdown Structure are nodes or so-called WBS packages (work packages). So when does a node become a work package? Here are some pointers:

• The work package can’t be decomposed any further
• The work package is small enough to be estimated for time and cost
• The work package can be assigned to a single person

The resulting WBS is a graphical, hierarchical chart where each node has a number to uniquely identify it.  If you are using Microsoft Project or other project tools, the WBS is also often shown as a so-called Gantt chart where each indention is a step down in the hierarchy until we reach the final work package.

Once the WBS chart has been established, we need to document the content of each package. For that purpose we must create the WBS Dictionary.  The dictionary includes a detailed description of each node and can also include whom it is assigned to, dates, cost, etc.

So what makes a good Work Breakdown Structure? Here are some pointers:

• The work package should be very detailed since they all define every deliverable on the project
• It is hierarchical like a pyramid (or Gantt chart)
• Each node should have a unique number and the numbering system should be logical to allow anyone to find the nodes easily
• It is thorough and complete. If something is not on the WBS, it does not get delivered
• The project team builds the WBS, not just the Project Manager

First let me ask you to think about which is better: To meet your customers’ expectations or to exceed their expectations. If your answer is to exceed their expectations you really need to read on.

I sometimes come across companies that proudly show me their corporate mission: “Our mission is to exceed our customer’s expectations”. So is there anything wrong with that? Absolutely! In my opinion there is no way you constantly can exceed your customer’s expectation. Let me give you an example.

A courier company has the mission to exceed their customer’s expectations. How can they do that? They can deliver the packages faster than promised. So if they promise to deliver in three days they can deliver in two days and by that exceed their customer’s expectations. If they do that for a while the customer gets to expect this and in order to exceed their expectation now they have to deliver in one day. Soon the customer gets to expect this and in order to exceed the customer’s expectation they now have to deliver same day. So slowly but surely the company will not be able to exceed their customer’s expectation simply because it is impossible.

My point is that you should never make it your mission to exceed your customer’s expectations. Instead just meet them.

When we refer to the project scope, we are referring to the work needed to successfully complete the project and only that work. Some companies have the same mission as the courier company in the example above thus they want to exceed the customer’s expectation. In a project they can do that by delivering more than they agreed upon. This practice is called “Gold Plating” and I strongly discourage you to gold plate any project and I will explain why.

What happens when we deliver more than we agreed to do? We increase the scope. Scope, schedule, cost, quality and risk are all interdependent, which means that if you change one the other ones will also change. So by changing the scope we also affect the schedule and especially the risks. We just made the project more complex, we are not getting paid for it, it was never planned for, we have to spend more time on it, and we just introduced a considerable portion of risk into the project; risk that we never had to add to the project in the first place.

What happens now if the additional scope causes other parts of the project to stop working or causes the timeline to expand? The project fails!

The project manager’s job is not to exceed the customer’s expectation but to deliver what was agreed upon and nothing else! If the customer wants additional scope to be added to the project, it is always handled in the Integrated Change Control process and if approved by the customer it may cause new baselines to be created. It may cause the project to be delivered at a later date or cost more but since that would result in new baselines for time and cost that is exactly how the project manager should handle that.

You may ask if trying to exceed the customer’s expectation is the same as the “Scope Creep”? They are closely related. The scope creep is often introduced and grows by allowing small additions to the scope without using change control and eventually all these little changes amount to a large scope creep that can cause the project to fail for the same reasons as gold plating since the scope and risk are affected. The main difference is that gold plating is a conscious decision by the project manager or his or her company to delivery more than agreed upon to honor their corporate mission.

If you, as a project manager, gold plate a project and allow the scope to increase without change control, your project has failed. It’s as simple as that. Even if you deliver the project with the additional scope on time and within budget, it is still a failure in my eyes. Why? Because you allowed unnecessary risk to be added to the project and that alone is a failure.

Earned Value Management (EVM) is the cornerstone of cost and schedule management for a project. It is used to determine how much value has been put into a project. This helps the project manager to report the progress of the project related to cost and schedule, so that adjustments can be made as needed to keep the project on track.

In order to understand earned value, think about the concept of debits and credits. For every debit to one account, there is a corresponding credit to another account. Earned value is similar to that if you spend one dollar on labor the project is “earning” a dollar’s value back into the project. Writing code, training users, writing documentation and any work you perform on the project, earn value back into the project.

Although there are many key formulas associated with EVM, I will only go through some of the more important ones.

For a project with a total budget cost of $100,000, I will go over the different values and formulas used in EVM.

Earned Value – EV

How much work was actually completed during a given period of time? This value is derived by measuring where you are in terms of work completed during the given period of time in the schedule.

Let’s say that you have delivered 25% of the project. In this case EV = 25% of $100,000 = $25,000.

Planned Value – PV

How much work should have been completed at a point in time based on the plan? This value is derived by measuring where you had planned to be in terms of work completed at a point in the schedule.

Let’s say that you planned to be 30% done resulting in a PV = $30,000.

Actual Cost – AC

This is the money spent during a given period of time (billed hours). In our example let’s say that the actual cost is $20,000.

Schedule Performance Index – SPI

SPI is the rate at which the project is meeting schedule expectations up to a point in time. In our example SPI = EV / PV = $25,000 / $30,000 = 0.83. This means that our project schedule is progressing 83% of the pace we expected, which is bad. Any number larger than 1 is desirable. Numbers less than 1 means we are behind schedule.

Cost Performance Index – CPI

CPI is the rate at which the project is meeting cost expectations up to a point in time. It’s an indicator as to how much we are getting for every dollar we spend. In our example CPI = EV / AC = $25,000 / $20,000 = 1.25 which means that we get $1.25 worth of performance for every $1.00 we expected, which is good. A CPI of 1 means that we are exactly on budget while a value of 1 or more is good, and value less than 1 is undesirable.

So for the example above, we are behind schedule since we only are progressing 83% of the pace we expected. However, we are doing fine on cost. We are getting $1.25 worth of performance for every dollar we expected.

So what can we use all these numbers for? Well, the project manager can now make the necessary adjustments to bring the schedule back on track at a point when the project is only 30% done according the plan. That’s much better than finding this out when the project is 100% done and we are late, right?

In our example the project manager can allocate more resources to the project to catch up to the schedule. That might end up costing more for a few weeks but there is room in the budget for this since we are under budget for now.

EVM is performed continuously throughout the entire project lifecycle and helps the project manager to keep the time and cost on track. It is also used in project performance reporting. Changes to the performance indexes can give early warnings allowing the project manager to make the changes needed to get the project back on track.

EVM includes many other formulas and indexes that are used during a project that I didn’t cover in this article, but I tried to cover the most important ones. If you like to know more about EVM, additional information can be found in this article on Wikipedia.

Quality Management is an important knowledge area and is concerned with “the degree to which a set of inherent characteristics fulfill requirements”. What does this mean? It means that based on the specified requirements we need to determine how well the solution fulfills these requirements.

When you are manufacturing widgets, it might be easy to set some quality standards for measurement, like diameter must have a tolerance of +-1 mm but how do you measure the quality of the deliverable of an IT project? That’s what I will try to explain in this article.

First let’s take a look at the project processes associated with the Quality Management Knowledge area.

There are three processes during a project that are concerned with quality. As with all knowledge areas, there is a planning process. Here we plan how the two remaining quality processes- quality control and quality assurance- are executed.

The most well-known quality process is to perform quality control. This is where we check if the deliverables are conforming to the quality that we expected. In IT projects where the deliverable is a software program; we have to check that each part of the total software solution is performing as expected. So how exactly can we do that? Testing, testing, testing!

In order to control the quality of a software program we have to build test cases. A test case is a procedural checklist that goes through a scenario inside the software. Let’s say we have built functionality of approval during an invoicing process. We now need to make sure that the software allows the approvals to happen correctly and does not allow invoicing until the approvals are done. We build a checklist with steps that a test person should go through in order to confirm that the functionality is performing according to the expectations. If the test case is successful, that shows the quality of this part of the software is adequate and we go on with the next test case.

In IT projects where the deliverable is software, there can be tens if not hundreds of test cases that must be performed to finally confirm the quality of the final project deliverable.

So what will happen if the quality control process approves a test case and later we find out that the software didn’t conform to quality; that the software failed to work even though the test case cleared it? Well, that’s what the last quality process is there for. It is called Quality Assurance.

Quality assurance is often confused with quality control but they are completely different. Quality assurance is part of the execution of the project and is concerned with overall process improvements. If the quality control processes are not adequate, this is where quality assurance comes in and handles the issues. So in the case where the software was cleared through quality control and later on failed is what quality assurance must deal with.

If something is not working correctly or we need to improve the quality control process, quality assurance goes in and investigates. Why did the test case not catch the issue we are now experiencing? What can we change in the control process and the test case to fix the problem in the future? Quality assurance is an ongoing process that makes the quality control process better and better. The goal is to make sure that the quality control is the best possible, and make changes as needed to ensure this throughout the project’s lifecycle.

Quality management is important because it ensures that the deliverable ultimately fulfills the project requirements and the customer’s expectations.

You may have heard about the critical path in a project and how the development of the project schedule is dependent on the critical path. As a project manager the critical path is essential to determine potential issues in our project schedule.

So what is the critical path and how do we determine it? Well, let’s first take a look at a network logic diagram for a simple sample project.

Each activity has a duration measured in weeks and the arrows show how each activity is depending on other activities to finish before they can start themselves. In the sample activity A must finish before C can start and D can only start once C has finished etc. We can also see that activity C can only start once both A and B has finished.

From the diagram we can determine three separate paths:

Start – A – C – D – Finish: 8 weeks

Start – B – C – D – Finish: 9 weeks

Start – B – E – F – Finish: 7 weeks

The critical path is defined as the longest path in the diagram and in our example it is path B-C-D that is the critical path of 9 weeks. What’s so critical about it? If one of the activities on the critical path is delayed the entire project is delayed!

If for instance activity D is delayed 1 week, the project will be delayed with 1 week.

But if activity E is delayed 1 week it will not delay the project because path E is on will just be 8 weeks and still be done one week ahead of the BCD path.

So the critical path is made up of activities that cannot be delayed without delaying the finish of the entire project.

What happens if activity E suddenly is delayed 3 weeks? In that case the B-E-F path becomes the new critical path of 10 weeks and the finish of the project is delayed. The project manager must now determine how to handle this delay or accept it as the new critical path.

Will a project only have one critical path? A project can easily have more than one critical path and in that case the project manager must know all of them.

So now that we know what the critical path is and how we determine it; how do we use it practically when managing a project?

We use it to determine if the project will be delayed if an activity is delayed. If the activity is on any critical path the answer is Yes! If not, it depends on if the delay makes the activity create a new critical path. If not, the answer is No!

A project usually have hundreds of activities and they usually have much more complex dependencies than our example, so project managers usually use software to set up the activities and dependencies and let the software calculate the critical path(s). If an activity is delayed the project manager can enter the delay in the software and see how it affects the overall finish of the project. It the project is delayed the project manager can use the software to rearrange activities, dependencies or suggest additional activities as needed to bring the project back on track.

The critical path is critical to the Time Management knowledge area. Make sure you know how to use it correctly next time you manage a project.

www.dilbert.com

Many projects fail for several reasons. One of the major reasons is “The Scope Creep”. First let me define what the scope creep is and how it can sneak in on a project.

When a project is first defined the scope is always a high-level scope as defined in the Project Charter and the Preliminary Scope Statement. The high-level scope is often accompanied by an Order of Magnitude Estimate of the cost that has a precision of -50% to 100% of the estimated cost.

As the project goes into the planning phase, the scope is defined in detail and for IT-projects it is usually established in an Enterprise Design Document (EDD). The EDD is used as a scope and cost baseline for the project. The cost estimate established as part of the EDD is usually much better than in the beginning with a precision of -10% to +15%.

So what can possibly go wrong now that the scope is well defined? More than most imagine! As the project continues into the execution phase, stakeholders change their mind about functionality, training, time lines, etc. If someone asks for changes to training requirements, functionality and time lines, they are changing the scope of the project. When that happens, it most often affects the time, cost and scope and a good project manager must execute proper change control to the project in the form of a project change request. This request must explain how the change will affect the project in regards to cost, time and sometimes also quality. The request must get formal approval from the project’s steering committee and a new cost and time baseline must be defined.

Does this sound formal and excessive? Maybe, but it’s the only way to control the scope. If the project manager just accepts the change as part of the existing baseline, the scope is different but with no changes to the project’s time and cost baselines. That’s the definition of the scope creep.

So what if we add a few hours here and there? Does it make such a big difference? Oh yes it does. If the stakeholders know they can add functionality or make changes to the time line without any repercussions, they will continue to do it. A training session is extended or postponed. Some additional functionality is added here and there. The amount of work is slowly increased and the time line is affected more and more. The scope creep is getting bigger and bigger from all these little changes that are allowed to slip through. And the result? The project is not delivered on time and within budget. The project fails.

So the application of change control makes all stakeholders aware that changes to the project may affect the time line and budget and in each individual case the steering committee must decide if they want to go forward with the change and also accept the change in cost and time. If they agree, they must formally accept the change request and the project manager will then calculate a new cost and time baseline that now becomes the current baseline for the project.

So can a project end up costing twice as much as original estimate and be delivered three months later and still be on time and budget? Yes, that’s the whole point of scope management. If the steering committee accepts changes to the project including cost and time changes, they also accept a new project baseline, thus the budget and the time line just changed for the project.

Scope Management is, in my opinion, one of the most important management tasks a project manager must do. Controlling the scope by applying vigorous change control and not accepting any changes to occur in the project without executive acceptance is crucial. If you ease up on this strict control, you risk losing control of the entire project and failure is most likely the outcome.

I wanted to let you know of a very useful tool when working with ERP systems or virtually any software programs.

I often have a table or some text that I like to export to Excel and continue to work on like a worksheet. Sometimes the software I am using will allow me to do the export but often it won’t. Especially graphical applications will have issues exporting to Excel.

The product I use is called Print2Excel and can be downloaded from http://www.print2excel.com.

Print2Excel allows any document to be exported to Microsoft Excel. It adds sophisticated functionality like printing profiles specific to each document or report, which allows you to customize how the information is presented in Microsoft Excel.

One of the great features of the software is that it will allow you to process the printout before it gets exported to Excel and allows you to strip headers, footers or specific text so you don’t get a lot of extra lines or columns that you have to delete afterward.

Since certain documents and reports require tedious data cleanup to be useful in Excel for further processing, Print2Excel introduces profiles. Profiles are a set of post processing settings, which Print2Excel can use for certain documents to quickly provide useful data in Excel. Via profiles advanced settings like removing certain data sections, blank rows and columns, apply certain text formats etc. can all be set specifically for one report or document type, so subsequent printing of these reports immediately makes the data available in Excel cleaned up and ready for the user to use.

I managed to get a promotion code that will allow you to get 10% off any number of licenses purchase through their website at http://www.print2excel.com. Use promotion code spring11 to get the 10% discount.

The cost of a project should be planned, quantified and measured. The job of the project manager is to tie the cost to activities and resources and build the estimates accordingly.

Most projects start out with a high-level budget before we know the detailed costs. The project manager often gets a budget for the project but instead of blindly accepting the budget the project manager need to review the scope of the work and the duration estimates created in the Time Management knowledge area in order to come up with a realistic budget. Budgeting by working from the detailed level is called a bottom-up approach and is much easier than working from the top down.

The overall recommended approach for detailed planning is to create the scope, then create the schedule and finally create the budget. In my opinion any other sequence will not make any sense.

This article will cover all the areas needed to successfully manage the cost of the project.

Cost Estimating
This process is part of the planning process group. This process is not only executed during the planning process but will be revisited many times during the project life cycle.
In order to be able to do any cost estimating we need to know the scope and the resource and duration estimating. Without that we won’t be able to do any cost estimations. There are many options for cost estimations.

So which one should we use to create the estimate? It all depends on the need. In the beginning where we only have a high-level scope we will only be able to do a Order of Magnitude estimate and later when the scope is more detailed we can create a Definitive or even a Control estimate. The rule of thumb is that, the closer we are to spending money for an activity the more precise the estimate will be.

In order to do the estimate we will utilize the Project Management Plan, Project Scope Statement and the Work Breakdown Structure.

Cost Budgeting
Many ask what is the difference between estimating and budgeting? Isn’t that the same? I agree that this can be confusing but a budget is also known as the cost baseline and it takes the cost estimate and maps it back to the dates on a calendar.

The cost baseline allows the customer to better plan for the expenses for this project including the cash flow. In order to be able to create the budget we must have the schedule developed and the cost estimating completed.

Most projects maintain some kind of financial reserve to protect against cost overruns. Typically projects will carry a 10-20% contingency reserve (or management reserve) that can be used for unforeseen events or risks.

Cost Control
This process is part of the Monitoring and Control process group. This process is primarily concerned with cost variance. A cost variance can either be positive (good) or negative (bad). The process ensures that the cost stays on track and that any change is detected whenever it occurs.
Like so many other processes in the process framework this process is revisited and executed many times during the project life cycle. Typically Cost Control is performed weekly during implementation where the project cost typically peak and monthly during the planning phase.
In order to determine how the project cost is performing we utilize Earned value Management. Please refer to my article on Earned Value Management for more information.

In most of my articles regarding project management I often say that the particular subject is important but Cost Management is very important simply because the customer is always very focused on price and any price increase will be very obvious to the customer unlike other project management areas.

This area deals with processes to handle procurement of goods and services that our organization can’t deliver.
The overall philosophy of procurement management is that it’s formal. This means that we are not just dealing with handshakes and a few emails back and forth; we are dealing with formal and legal contracts with our subcontractors and vendors.

There are six processes in procurement management.

Plan Purchases and Acquisitions
Here we take a look at the project and determine which components and services of the project that we can handle internally and which ones we need to outsource. This is also called and Make-or-Buy Analysis. Hereafter the project manager needs to determine what kind of contracts we need to put in place.

There are several contract types that could come into play:

Plan Contracting
In this process we create detailed documents such as Requests for Proposals or RFPs. The RFP explains what is expected of the seller in terms of what should be done, when it should be done by, cost, time and quality etc.

Request Seller Responses
This is the process where we distribute the RFPs and other procurement documents to potential sellers and have them respond to the RFP. We usually provide a deadline for all responses.

Sometimes we can also set up a bidder conference to allow sellers to ask questions. This is most often used of the requested services or goods are complex in nature and instead of answering the same questions several times in separate communications we can handle it all in one conference session.

We can also elect to advertise the bid to the public on websites or in newspapers. In some cases this could be a requirement by law, so make sure to check if this applies in each case.

Select Sellers
Now it is time to select the sellers from the received responses. The selection can be based on price, quality, delivery time etc. As the project manager it is up to you to determine which sellers are best for the project and select them accordingly.

Contract Administration
Here we review the contract and determine if the results match the contract. Were the goods and services delivered? Were they delivery on time? Were we invoiced the agreed amounts? Other contractual obligations can also be considered here.

Contract Closing
Here we are handling completing the contracts and terminating them officially. Hopefully the seller delivered according to the contract and we paid according to the contract, but contracts can unfortunately also get closed for non-delivery, non-payment etc.
One thing is for sure. Contracts must be closed one way or the other. In order to eliminate risks to both parties, closing the contract makes certain nothing else is going to be delivered or paid under the contract.

This knowledge area is primarily concerned with resources, activities and scheduling. As project managers we always want to be in control of the schedule and not the other way around.
Using the scope baseline we build the schedule from the ground up.

The key input to the knowledge area is the Work Breakdown Structure or WBS. There are six processes in this knowledge area of which five is in the planning process group and one is in the monitoring and control group.

Activity Definition
Based on the scope baseline and the WBS we break each work package into all the activities needed to deliver the particular package. This is also called activity decomposition and involves breaking down the package into activities that may involve multiple groups of people. From here we can now derive an activity list that can be used by the next three planning processes.

Activity Sequencing
We will use the activity list derived from the last process and put all activities into the correct sequence. Some activities may depend on another activity being finished and that’s what we deal with in this process.
We typically create diagrams to visualize how each activity needs to fit into the bigger picture.

As we are building the sequence we can insert lead and lag time as needed. Lead is simply letting an activity start ahead of another activity. An example related to IT could be that we developed software that needs to be tested but we are able to provide a preliminary version of the software for testing before it is completely done. That way we can speed up time.
Lag is waiting time between activities. An example of lag time could be shipping time between two activities. It takes a few days to get something needed for the new activity to start.

Activity Resource Estimating
For each activity we also have to determine how many resources we need to complete the activity. This is important to be able to do cost estimating later on.

Activity Duration Estimating
Here we take each activity and find out how long they will take with the resources allocated.
This gives us an estimate of the total number of hours needed including inventory items and/or fixed assets.

Schedule Development
Based on all the previous planning processes in this group we are now able to create the project schedule and that becomes the time baseline for the project.

The project schedule will typically be shown as a Gantt chart but can also include a Milestone Chart and other charts used to support the project time baseline.

Schedule Control
This is the only process that is not regarding planning. It is a monitoring and control process where we compare the work results to the plan and ensure they line up. Like with many other project management processes we have to be proactive when controlling the schedule and not sit around and wait for problems.
In order to calculate how the project is progressing we can use earned value management to determine if we are ahead or behind schedule (see EVM article).

You may say that creating the time baseline is a lot of work and I agree it can be cumbersome and tedious to create the schedule but there is no getting around it. We simply have to do it. Fortunately there are software programs (like Microsoft Project) that can assist you with all the time management processes and can save you a lot of time but also give you a lot of control. Project Management software also allows you to do what-if scenarios and calculate the impact in minutes instead of having to manually redo the schedule to accommodate the new situations.