Category: Project Management

Project Cost Management

Keith Custer, in his article “The Seven Deadly Myths of Earned Value Methods in Project Management” (Custer, 2009), describes how Earned Value Management (EVM) is misunderstood as a tool for managing costs in a project.

Keith Custer, in his article “The Seven Deadly Myths of Earned Value Methods in Project Management” (Custer, 2009), describes how Earned Value Management (EVM) is misunderstood as a tool for managing costs in a project. He points out that there is a fear of implementing EVM with detractors saying it is difficult and time consuming. They also claim that EVM is better suited for large ($1M+) or government projects but not for smaller projects (Custer, 2009).

But Custer claims that the process laid out over forty years ago is as appropriate for small as well as large projects and actually makes it easier to effectively manage them (Custer, 2009). In his article Custer lays out 7 myths about EVM stating his case as to why each of these is invalid.

EVM Myths in Managing Project Costs

Myth 1: That only contractors and government projects need use EVM (Custer, 2009). Custer points out that the reason why government and contractors use EVM is precisely because it is so effective at controlling project costs (Custer, 2009). In fact, it is effective as an estimating tool. Properly documented estimation can be more effectively tracked than hastily thrown together estimations. Custer also points out that the government borrowed EVM from industrial manufacturers who had developed the process early in the 20th century (Custer, 2009). He refers to the fact that like many projects in private industry, government projects are notorious for being under estimated and for costly budget overruns (Custer, 2009). The Office of Management and Budget (OMB) has consistently discovered in study after study that those projects run using EVM they rarely under estimate and rarely has significant budget cost overruns (Custer, 2009). In fact, data gathered since mid-1970 has shown a significant improvement in the ability to scientifically forecast the outcome of a project at the 20% completion mark (Fleming & Koppelman, 2010). Both Custer and Fleming point out that EVM’s WBS, schedule constructs, organizational breakdown structures, reporting, variance reporting provide a significant boost to estimating, project performance tracking and forecasting at any given point in the project (Custer, 2009) (Fleming & Koppelman, 2010).

Myth 2: EVM is only useful for large or long term projects: Any project of any size can benefit from EVM, according to Custer (Custer, 2009). And he is right. I have used EVM on projects ranging from $50,000.00 up to $8 million with great success. With smaller projects you have to increase the frequency of the reporting cycle so that you get timely results from monthly to weekly to daily depending on the duration of the project (Custer, 2009). The key point here is that EVM can alert the Project Manager to problems with the budget and schedule at any given point, but there is work involved. The work, though, is what I would consider to be minimal amount required for any size project: Scope, WBS, schedule, regular reporting.

Myth 3: EVM is too rigid: As I stated above, any good Project Manager knows that the minimum requirement for managing a project is scope, WBS, schedule, and regular reporting (Custer, 2009). Custer emphasizes that EVM requires strict detailed up front planning and quantifying of expected results (Custer, 2009). But to say that EVM is too rigid is completely wrong. In fact, it’s very flexible where many of the tools can be constructed to suit your needs on the fly without any negative effect on the data (Custer, 2009) (Fleming & Koppelman, 2010). One thing that Custer points to is the successful use of EVM in defense projects where there are huge risks involved (Custer, 2009). In many of those projects only the near term scope was known with many details not known for many years. The key, as noted by both authors, was a well-developed WBS that gave the Project Manager the flexibility needed to use EVM effectively (Custer, 2009) (Fleming & Koppelman, 2010). A project I’m currently running has a WBS that is not well-developed and my aim is to apply the rules of EVM to bring it into alignment so that I can use it as the tool it is meant to be.

Myth 4: There is such a thing as EVM lite: As noted earlier, yes, there is a sort of EVM lite (Custer, 2009). But you still have to do the work of developing a scope, WBS, schedule, and regular reporting. Custer refers to the many software companies that proclaim an EVM Lite version are really trying to just sell their software (Custer, 2009). The problem is that these companies leave out important aspects of the process, such as implementing management recommendations resulting from the EVM data gathered. Custer asks what the sense is in gathering the information if you’re not going to use it (Custer, 2009). Good point, I have seen many a Project Manager gather together the information, only not use it because it was not good news in their eyes. Never mind that the point of the information was to give management a truthful view of the status of the project so that they could make good decisions.

Myth 5: Implementing EVM is a lot of extra work: Yes, it is hard work, but not extra work since it’s work the Project Manager should be doing already. EVM is a process that allows the Project manager to use the information gathered and organized more effectively. It helps to draw out a clearer picture of the true status of the project. The EVM standards only reinforce the good project standards that should already be in place. EVM actually helps to integrate them (Custer, 2009).

Myth 6: Companies need to change their structure to implement EVM: While EVM requires that the WBS define who is responsible, the department and individual, it does not require a change in the organizations structure (Custer, 2009). Even in a functional matrix organized company, EVM only requires that each department be listed as to what they have agreed to do (Custer, 2009). In fact, EVM works very well in cross-functional organizations in tracking the costs of the project and rolling those costs up to the project level (Fleming & Koppelman, 2010). At Walgreens we use an EVM lite that was internally created in which accounting developed a system for tracking each project costs by department.

Myth 7: Implementing EVM requires expensive software: No specific software is required (Fleming & Koppelman, 2010). Many basic software’s such as Excel, MS Word, MS Project work quite well with EVM.

Conclusion

Controlling the costs of the project is one of the most important responsibilities assigned to the Project Manager. As has been pointed out, controlling project costs can be done quite effectively from estimation to project completion using EVM. Custer and Fleming point out, regularly, that the EVM processes and tools help the Project Manager to effectively estimate the cost of the project; to determine at any given point the true status of the project; and to accurately forecast its outcome even when only 15-20% of the project is completed (Custer, 2009) (Fleming & Koppelman, 2010). Like with any undertaking, you have to create the tools needed effectively and then use them effectively so they work for you. As I stated earlier, many of the projects I have managed were in poor shape when I inherited them. I had to literally rework the scope, the WBS, the project schedule so that I could use the EVM tools and processes to keep control of the costs of my projects. The tools and processes work. All you have to do is use them.

References:

Custer, K. (2009, January 21). The Seven Deadly Myths of Earned Value Methods in Project Management [Web log post].

Retrieved from http://www.projectsmart.co.uk

Fleming, Q. W., & Koppelman, J. M. (2010). Earned value project management. Newtown Square,

PA: Project Management Institute.

Kendrick, T. (2009). Identifying and managing project risk: Essential tools for failure-proofing your project.

New York: AMACON.

Lipke, W. H. (2009). Earned schedule: An extension to earned value management– for managing schedule performance.

Raleigh, N.C.: Lulu Pub.

Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK guide), fifth edition.

Newtown Square, PA: Author.

Verzuh, E. (2012). The fast forward MBA in project management, fourth edition. Hoboken, NJ:

John Wiley & Sons.

Westland, J. (2006). The project management life cycle: A complete step-by-step methodology for initiating, planning, executing and closing the project

successfully. London: Kogan Page.

Risk Management: A Discussion

Having spent over 20 years in project management I have had the opportunity to determine risk in my projects many times over. In some companies I have worked for risk would be identified, analyzed, and a mitigation plan would be created. The risks would be carefully watched and acted upon should it become an issue. Other companies would allude to risks, even list them, but stop there with no further attention. They figured they had covered their bases and need not do any more. As Verzuh points out, risk management needs to be systematically approached (Verzuh, 2012). If a lackadaisical approach is taken it will show when a risk becomes an issue and there is no plan in place to handle that risk.

Risk Management is Beneficial
Risk management is used to diminish possible threats to your project. One project contract I worked was for Uline, Inc. out of Pleasant Prairie, WI. Uline is a distributor of shipping products. They supply everything from bubble wrap to boxes. They create a huge catalog that is mailed to over 30 million customers in North America twice a year. Their eCommerce website looks just like the catalog. It looks that way because the owner, Liz Uihlein insists on it. In fact, I was told it was near impossible to get her to change that look. Uline does over $3 billion in revenue per year, 54% comes from online sales.

I was tasked with developing a project plan for redesigning the UX for their eCommerce site. Upper management had gotten permission from Mrs. Uihlein to remove a left side column that had been used for advertising. This meant a major restructuring of the site. The management team also knew they needed to develop a detailed plan to manage this project successfully.

One of the first tasks I worked on in creating this project plan was discussing the importance of defining risk. What I try to point out to my team is that risk is not as painful a process as they believed. Verzuh points out that the easy risks are the ones we know. He called these known unknowns because we know they’re potential problems, we just don’t know if or when they will occur (Verzuh, 2012). With Uline we had plenty of known unknowns. Verzuh also points out the unknown unknowns, those problems that happen unexpectedly (Verzuh, 2012). In Uline’s case there were no unknown unknowns, but I wanted to plan for them so we would be prepared in case something happened, which inevitably it does.

Creating a List
Planning is a great source for determining potential risk in your project. As requirements are gathered you begin to create a Functional Requirements Document (FRD) based on the Business Requirements Document (BRD) (Westland, 2006). Creating these documents involves many resources such as technical leads, systems architects, UX designers, Business Systems Analyst (BSA) and Business Analyst (BA) as well as subject matter experts from the business.

You can do all the brainstorming sessions you want, but from my experience nothing brings out potential risks more than determining what functionality is needed to create the business requirement. Verzuh even points out that detailed planning is an opportunity to discover risks (Verzuh, 2011). In these documents we describe what the system is supposed to do, how it is supposed to work. We begin to identify what capabilities are needed to meet those requirements.  We start to create the work breakdown structure (WBS) that defines each of the tasks required to accomplish the requirement. We create the WBS dictionary that describes the work, the assumptions and constraints in great detail (PMBOK, 2013).

Other documents we used to gather input from included the Scope document, the Charter, the project schedule, the stakeholder register, the quality management plan as well as activity cost and duration estimates (PMBOK, 2013).

As the requirements, scope definition documents, WBS, and other project data started to take shape, we began to develop a list of specific issues, concerns, and risks related to the scope and deliverables of the project. It was here that we started to identify and catalog those risks using a risk register. We developed a series of questions that helped us to further identify risks called a Risk Profile:
•    How many teams work on a given task from start to finish?
•    How much time do they devote to each task?
•    How does the task get passed over to the next team?
•    Is there a method for tracking each web page?
•    How does each web page get approved?

These were just some of the questions we asked, but from these questions we could identify potential risks; bottlenecks in the system for instance, that could cause the progress of the project to slow down.
A good risk profile is industry and organization specific, and according to Verzuh, it should address both product and management risks (Verzuh, 2012). One major specific concern to the organization of Uline was the time it took to complete tasks due to its cumbersome work/approval process. We determined that a web page from start to finish was touched by no less the 34 hands plus 10 approvers. The company had never put into place any mechanism for tracking where in the process a given page was at any given moment. A common complaint was trying to locate who had a page, who was supposed to get it next, and if it had been approved.

Ranking the Risks
As we developed the WBS we identified many risks, and while developing the WBS we would analyze each of those risks. The team would assign a probability to each risk, asking how likely it was that this risk would occur?  We entered this information into a Risk and Impact Matrix which helped us to categorize the risks from highest potential to lowest potential. By ranking the risks we were able to determine which risks we needed to concentrate on first and which ones could wait till we learned more from requirements definition. This helped to save time and we could concentrate on the crucial risks for developing our response in the event that risk turned into an issue. Mitigation plans were developed for those risks with the highest probability of occuring. PMBOK (2013) describes this process of prioritizing risks for further analysis as quantitative analysis.  We didn’t get real fancy about it. We used a simple numbering system with a range from 1-10 with 10 being the highest rank, to rank the risk. By definition the difference between a risk and issue is that a risk is an issue that hasn’t occurred.

Describing the Risk
So, documenting risks is crucial. But getting the team to take the time to document is the challenge. Many of the risks were initially written simply as “There is a risk that a document won’t be approved”. And the mitigation plan was: “We will monitor it”. The actual risk was that at any given moment a web page could sit on an approver’s desk for more than the planned for duration which was one day. The question was how do you hasten the process along should this event occur? Just as important: How do identify its occurrence?
In the risk register we had a column for stating/describing the risk. In this column we succinctly described the potential risk so that anyone could clearly understand what the risk was. We described the impact this could have on the project if it occurred. We identified the teams impacted by this risk. We categorized each risk by what department and the type of impact; scope, schedule, budget. Each risk was given an id number so we could easily track it.

An Example
We had identified a risk as the bottle neck that could occur in the work/approval process. We had ranked this risk as highly likely to occur. Our first risk: The approval process could be held up due to an approver not completing their task within the planned for duration. A second risk: The project not knowing the location of a web page at any given moment in the process. Our mitigation plan addressed the need for a method to identify the location of a web page at a given moment in the entire process that was available to the team and was in real time. We needed to map out the entire process from end to end. We proposed building an application that would allow handlers of the web pages to indicate that they had just passed a web page along to the next handler. The thought here is that everyone likes to get tasks off their desk but are not so willing to indicate right away that they just received the assigned document. So, the responsibility of indicating in the system was given to the passer rather than the receiver. Now it was incumbent upon the receiver to want to become a passer. That application would show where the document was, when it was received, thus how long the receiver had it in their possession. It would also allow for the page to be approved in order of approver to show all the completed approved documents had been done according to company hierarchy. Thus our mitigation plan for identifying a bottleneck minimized the chances of the risk occurring was to build an application that helped us to administer the process.

Contingency Plan
Once we had properly identified, analyzed, prioritized, created a set of preventative actions to reduce the likelihood of a risk occurring, developed a response to mitigate should a risk occur, we had to determine what the costs of our preventive actions and/or responses was going to be. In the case of creating the application for tracking a web page, it was how many hours it would take to create the application? Thus more iteration as we had to plan the applications functionality and design, we had to identify/define/mitigate the risks associated with this side project as it would be handled by a different team. Verzuh(2012) and Kendrick (2009) both point out that risk management happens repeatedly throughout the project, that risk management is truly an iterative process. Our contingency plan included money in the budget that could only be expended if the event occurred. We had to keep in mind that this was money that would be tied up for the life of the project or until the threat of the risk passed. The contingency plan also identified ways in which to adjust the schedule so as to minimize any affects to it if the risk occurs.
Contingency plans are like insurance; they’re nice to have in case something happens. Just remember they don’t come cheap. You will be tying up that money in the contingency fund for the life of the project or until the risk becomes a moot issue.

Managing the Risk
We realized early on in the planning of this project that we would need to continuously plan for risk. We knew that we needed to create a plan that not only would have a process for identifying future risk, but would also include how we would analyze it, prioritize it, categorize it, deal with it; in other words, how we manage future risks. By documenting this process you are working towards minimizing any potential unknown unknowns that could have an impact on the project. Even though we had not identified any unknown unknowns, that didn’t mean they didn’t exist. A portion of our contingency funds were just for those unknown unknowns.  We realized that if it could go wrong, it would. And in this project there was much that could go wrong.

Risk Register
As discussed earlier, we had created a risk register. This tool would be used to track our risks as the project progressed. We used the information gathered during our planning to fill out the form. Such information as the risk identifier, risk description, status, risk cause, the probability of occurring, the impact on the project should the risk become an issue, the risk score, and our response (mitigation). It included spaces for revised probabilities, impacts and scores should conditions change. The register also showed who was responsible for tracking a risk. The communication plan called for making the risk register an agenda item for each team status meeting. Making the risk register an agenda item meant the risks would be monitored closely. The object was to make sure the team was doing the planned work to minimize the effect or responded quickly to minimize any effect on the project should a risk occur.  What the responsible member of the team will be looking for is the trigger event signifying the occurrence of the risk. Once this trigger is pulled we can begin to enact the mitigation plan we have in place.

Conclusion
A number of stakeholders would rather avoid risk analysis altogether. I think a major part of a Project Managers job is to ensure the proper planning for the eventuality of a risk occurring. This is a far better reaction to a risk then avoidance. The problem here is that avoidance may mean changing the scope of the project opting instead for a less than satisfactory solution. As in investing, there is a reason why low/risk securities have a low return. Remember that the harder the risk is to detect, and the larger its impact, the greater cost required in higher contingency dollars and time. One need only imagine the cost incurred for failing to plan for risk when that risk occurs.

In Uline’s case, the biggest risk was a bottle neck being created due to the approving process. We put into place a mitigation plan to minimize the impact which would be implemented thus minimizing the impact greatly.

Risks need to be planned for. If they’re not planned for, if they’re not well thought out, and they’re not communicated to all stakeholders, then your project is doomed to failure.

References:
Kendrick, T. (2009). Identifying and managing project risk: Essential tools for failure-proofing your project. New York: AMACON.
Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK guide), fifth edition. Newtown Square, PA: Author.
Verzuh, E. (2012). The fast forward MBA in project management, fourth edition. Hoboken, NJ: John Wiley & Sons.
Westland, J. (2006). The project management life cycle: A complete step-by-step methodology for initiating, planning, executing and closing the project successfully. London: Kogan Page.

Risk Management

Eric Verzuh notes that sometimes it seems that for every risk problem solved a new risk appears (Verzuh, 2012) and that can be so true. Perhaps the biggest risk to a project is when the team skips risk analysis because they consider it unnecessary.  Out of the 5 risk strategies described by Verzuh: Acceptance, avoidance, contingency planning, transfer and mitigate, he seems to have forgotten one…ignoring…hoping it goes away. What I will describe here, briefly, is where the team decided a possible event wasn’t going to be a risk, and there wasn’t much evidence to support it as a possible risk, yet it eventually turned into an issue.

Kendrick describes a risk as almost any uncertain event associated with work. It’s as the insurance industry characterizes risk as loss multiplied by likelihood. I was the project manager of a project that was developing an intranet system that the U.S. Navy would use to manage the recruits at three naval bases in the Midwest, south, and eastern parts of the country. The navy had a big interest in using current web technology to develop applications that could be used to manage recruits from boot camp to deployment. When I first started I was a one man team doing mostly proof-of-concept (POC) work.

Two years into the project, by then I had a team of 15, it was decided we should re-locate the web and data servers housing this system to a server farm located at Pensacola, FL. The navy has two bases located on the peninsula, virtually on opposite sides. While developing the requirements for this project we discussed some of the risks we would face. Most of the team was worried about working with servers located almost 1000 miles away. They felt a big risk was losing internet connectivity. They also felt that not having direct managerial control was a risk; basically we wouldn’t be in control of the box anymore and they were not happy about that.

The process I recommended we follow was basic PMBOK: Plan risk management; identify the risks; perform qualitative and quantitative analysis; plan the risk response; and control the risks. While identifying risk was ok with the team, they weren’t exactly thrilled with having to develop a response to each risk. One risk I identified was the possibility of a hurricane wiping out the entire server farm. Everyone disagreed with me. I had pointed out the bases, and both the main server farm and the back-up server farm, were located in Florida, on the Gulf of Mexico, and on a peninsula. They felt that there was sufficient protection that a hurricane could never wipe out the entire farm. I asked them to humor me, let’s develop a mitigation plan just in case. They said ok, but it was never completed. My resources were all working for different departments, only part of their time was devoted to this project.

Some of you may remember a hurricane named Ivan. Ivan, a category 5 hurricane, hit landfall just west of Pensacola back in 2004. Ivan had a surge wave that was reported to be 26’ tall. Ivan basically wiped out the back-up server farm first, and then the main server farm. And we had no back-up plan in which to keep the system alive. Or so they thought. I guess this is one reason why I’m a project manager. I had a back-up system created at Great Lakes just in case. Cost was minimal as I used the old servers we had used before to run the system. I had created a contingency fund and I had a program created to monitor the systems in Florida. If either one lost connectivity the spare servers would immediately back up the entire system.

The lesson learned here is that as a project manager I have to be prepared for any and all types of risks. If it’s difficult to get your team to prepare the plan, then do it yourself. In the end it’s your job on the line if a risk becomes a reality and you didn’t plan accordingly.

References:

Kendrick, T. (2009). Identifying and managing project risk: Essential tools for failure-proofing your project. New York: AMACON.

Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK guide), fifth edition. Newtown Square, PA: Author.

Verzuh, E. (2012). The fast forward MBA in project management, fourth edition. Hoboken, NJ: John Wiley & Sons.

Business Strategy and Project Management

One of the main reasons that projects exist is because of how well the concept fits into helping businesses meet their strategic goals and to respond to current business conditions. Quite honestly, business strategy and project management go hand in hand. Businesses today are forced to be much more agile than they were 30-40 years ago. Business have to deal with a climate that includes shorten product life cycles, increasing technical capabilities, agile competition, all of which make it a necessity to be much more competitive and agile in order to meet that competition and serve customer needs (Cleland 1998)

Today’s Business Climate
In today’s business climate business has to be able to organize a group that can solely concentrate on one objective that meets a business’s strategic goal or need. “Projects are the means for achieving strategic goals. Entering new markets, driving down costs, delivering innovation— all are achieved through projects (Verzuh 2011)”. What businesses have to do is to carefully determine all they can do with the available resources they have.

This means they have to have a steering committee, made of management and stakeholders who have skin in the game, who make the decisions on which projects will be approved. They will base their decisions on how the proposed project fits into the company strategy. They will ask “how well does the proposed project utilize the available resources and at what cost? Which project is going to get us the most bang for our buck?”

Project Portfolio Management
I have worked for companies where “Project Portfolio Management (PPM)” (Verzuh 2011) was handled quite successfully. “It ensures that projects and programs promote organizational strategies and goals” (Verzuh 2011). I’ve worked for some where it wasn’t handled as well and you ran into a Vice-President’s pet project that would suck away all of the resources you thought were committed to your project. The object of the PPM is to ensure that only those projects that move the company towards its stated strategic objective shall be approved. PPM “accomplishes that by avoiding the common trap of trying to do all projects in the midst of limited resources. It requires disciplined decisions driven by agreed-upon priorities.” (Verzuh 2011)

But PPM cannot work if it isn’t organized correctly and the company is not dedicated to adhering to its principles. PPM can bring a balanced portfolio of projects that help a business to achieve its strategic goals while delivering the highest return on its investment.

It’s much like changing from Waterfall as a project methodology to Agile as a methodology. If you’re not fully dedicated to it then it won’t work.
At Walgreens we use a hybrid system that continually needs tweaking. They have a project intake group that reviews the submitted project idea forms. The project idea is reviewed by the Intake Steering Committee made up of the directors of the various team divisions from within the BSS Retail Group. They determine if the project fits into the business strategy and in what way it fits (does it add value or is it a fix). Once the committee approves the project for further review it is assigned to a Project Manager. The project proceeds to identify all impacted teams and develops all the supporting documentation including a high level business requirements document, the project charter, a high level functional requirements document, and what we call an E0 ROM budget estimation (+/_50%). The business requesting the project, and the Intake Steering committee, use the information gathered by the Project Manager to make a determination on the project.

Conclusion
Ultimately, a company that doesn’t develop some kind of process in which to review and approve projects stands losing because it will have wasted resources, time, and money. That business will ultimately find itself out of business as much better organized businesses that understand the value of PPM will beat them to market.

References:
Verzuh, Eric (2011-11-03). The Fast Forward MBA in Project Management (Kindle Locations 9926-9927). Wiley. Kindle Edition.
Cleland, D. I. (1998). Strategic project management. In J. K. Pinto (Ed.), The Project Management Institute Project Management Handbook (pp. 27-54). San Francisco:          Jossey-Bass.

Measuring Project Success, a discussion about Triple Constraint:

Jack S. Duggal, MBA, PMP in his article “Next Level Up: How Do You Measure Project Success? Rethinking the Triple Constraint” (PMI Community Posts, 9 July 2010) poses the question of whether a Project Manager feels trapped by the traditional triple constraint of Scope, Time, and Cost? Mr. Duggal thinks we need to look at the whole concept differently, especially in light of companies demanding that projects fit into the strategic goals of the company. We need to redefine the definition of success:
“Projects that are delivered on time, within budget and meet scope specifications may not necessarily perceived to be successful by key stakeholders.” (Duggal, PMI Community Posts, 9 July 2010)

Other criteria for project success
Mr. Duggal proposes that project managers need to take into consideration other criteria for measuring progress success. In a survey conducted by the “Projectize Group” in 2008-09 project stakeholders listed such things stakeholder satisfaction, meeting business objectives, customer/end-user acceptance, quality, and benefits as being necessary to determining project success.
“An important concept to understand is that time, cost and scope are related to project outputs, whereas the other factors are related to business outcomes.” (Duggal, PMI Community Posts, 9 July 2010)

I agree that ultimately business outcomes along with strategic goals is what drives projects, it is the job of the project manager to ensure that the project stays aligned with those business goals by using the iron triangle effectively. By controlling scope, time, and costs, the project manager can bring the project to a successful conclusion while meeting the strategic goals of the business.

Fitting the “Other” criteria into the Triple Constraint
Stakeholder satisfaction can be met through a clearly defined project scope. In the scope the object and the goals of the project need to be clearly defined to meet the expectations of the business and the stakeholders. Ultimately they are the ones who approve the scope of the project. The project manager needs to ensure that the scope defines how the object of the project will be met. He needs to ask and get answered the question of what is the purpose of the project: What need or problem is the project supposed to fulfil or solve? What business outcome is the end result?

I see the definition of the scope as the first means by which the team begins to make the connection between the stated business goal and the means by which to achieve that goal. One of the tools that incorporate the scope is the project plan, including the Work Breakdown Structure (WBS). In the WBS the project team defines the work needed to achieve the business goal. It breaks the work down into manageable work packages, sometimes referred to as activities. The duration of time it takes to perform these work packages is estimated which ultimately leads to our budget. The stakeholders will have to review and approve the schedule that gets produced after the WBS is completed. All this activity brings a greater understanding of the strategic business goal the project is helping the business to achieve.

Mr. Duggal suggests that we “mirror outputs with business outcomes”:
“While focusing on each of the triple constraints, the project manager has to reflect and make project decisions based on the achievement of the corresponding business outcome. Cost and time focus has to optimize business benefits like ROI, NPV, etc.,” (Duggal, PMI Community Posts, 9 July 2010)

He feels that user acceptance in the end has to be the ultimate goal of the project. I agree because ultimately user acceptance has to be achieved in order to bring the project to a successful conclusion. In order to optimize ROI and NPV the project has to successfully meet a business need, a corresponding business outcome. After all, why else would we be performing the project if not to meet a business goal? In my own experience I have noticed that when you have a clearly defined scope you get better performance from your team. The team doesn’t like to do work that has no positive meaning.

Parallel Balance
Mr. Duggal suggests using a parallelogram, rather than a triangle, as a way to view managing the contending forces that pull at a project. Each side of the parallelogram would represent the following:
1. Budget
2. Scope
3. Schedule
4. Business benefits/outcomes

The Project Manager would balance budget with scope and schedule or scope with schedule and budget. Business benefits could include strategic goals, user acceptance, and customer satisfaction.

Diamond of Opportunity
The diamond of opportunity looks at tactical project outputs with strategic business outcomes. In other words, does the project align with the expected outcome; are we getting what we’re asking for. Mr. Duggal feels that multiple sides of the diamond help the project manager include multiple levels of focus that may be relevant to the business.

Conclusion
I think that Mr. Duggal ideas carry merit due to the importance of user acceptance of the projects output. The project has to meet the business needs or solve a problem otherwise it has no real reason to exist. But I also feel that the traditional triple constraint iron triangle effectively incorporates the desires of the business because it forces the team to focus on what is really necessary to achieve the goal.

References:
1. Duggal, J. (2010-09-10). Next Level Up: How Do You Measure Project Success? Rethinking the Triple Constraint. Issue of PMI Community Post

5 Ways to Managing Your Time – Some Ideas

Wouldn’t it be nice to have a few more hours in your day? Many project managers would love it! Sometimes it feels like you can’t get everything done. What you need to do is manage your time better. Here are some suggestions:

5 Ways To Manage Your Time

You’ll get more done in less time!

#1. Timesheets
Think about where your time is going. Do you really know what you work during the day? Are you tracking how you use your time? Timesheets can show you exactly how much time you spend on many activities such as creating reports or responding to emails. There’s the 15 minute break to check Facebook that turns into 30-45 minutes…

Tracking your time lets you know where you’ve been and where it’s going. This will help you to better prioritize your time and make you more conscious when it comes to managing your time.

#2. Task lists
Get yourself going in the morning by organizing what your priorities should be the day before. Organizing task lists helps this. A clear list will tell you precisely what you need to be working on as soon as you walk in the office. If you add in a column for dates it will also tell you what needs to be completed by when, which is a huge help when it comes to scheduling the top priority tasks first.

The task list feature can be organized using many of the different apps available today on a smart phone. On my iPhone I use the reminders feature, calendar, and an app called SuperNote. What is nice about these is I can dictate by voice the task information right away and not have to try to remember details I didn’t write down. I make it a point not to try to commit everything to memory.

#3. Milestones
Milestones are a good way to manage your time as they put focus on the an intermediate goal. Putting milestones on your project plan forces you to review them regularly with your team. You can be sure to align an upcoming deadline with the milestone objective to a date on your task list.

Most milestones relate to project tasks but you can also create personal milestones on the apps discussed in item #2 to remind you about scheduled dates for other tasks on your task list.

#4. Automation
As Project Managers preparing reports is one of the tasks that takes the most time in any project. Getting status updates from team members, organizing the data, checking it, formatting it, reviewing statistics, then checking it again and sending it to the stakeholders. It never seems to end.

Automation of the information inflow can help to make these tasks easier. Set up your report templates to pull data from MS Project (or whatever PM software you’re using) so it shows the status in real-time. Automate in the beginning make for one less job for you to do.

#5. Saying no!
Just say no. You cannot do everything and a good PM knows how to delegate. And you don’t have to do everything. Many times you can’t take on more work. And if a stakeholder is insistent, ask your the project sponsor what they want you to drop. What top priority items should be moved to the bottom of the priority list?”

It isn’t possible to get everything done, especially if it’s out-of-scope items. Negotiate priorities with your stakeholders so that your projects aren’t overloaded, they’ll appreciate that you’re being realistic about what can be done in the time available.

Try these 5 tips for managing your time, you’ll be pleased to see how many extra hours you can find in a day. You’ll also be pleased with how much stress you have let go because you’ll be better organized to get tasks done in a timely manner.

WBS Explained

WBS stands for “Work Breakdown Structure”. Simply put, it delineates the work required to complete the project. A WBS makes a Project Managers life easier, and it ensures a complete understanding of the work required to complete the task at hand. A WBS is the delineation of the scope into work packages and activities required to complete successfully. It represents total project scope as well as product scope.

I have witnessed during my time as a Project Manager many a practicing project manager not using the WBS correctly or at all. Many find it burdensome; others think it’s useless, and others just do not understand how it. What’s worse is when management sees no value in the exercise of putting a WBS together.

A WBS is easy to understand and quite easy to create. It has immense effectiveness serving as an anchor for many a successful completed project. There are numerous publications that can guide you in developing a WBS. I will focus on the importance of a WBS to the project and some detail on writing one.

A WBS takes time, thought, and collaboration. It should have a method for identifying the hierarchy in either a hierarchical chart or as an outline. It should include a WBS Dictionary that explains in detail how to complete each package/activity. The dictionary spells out the expectation of the deliverable.

  • A WBS can receive information from:
    • The scope management plan
    • The scope statement
    • The requirements document
  • The WBS is related to:
    • WBS dictionary
    • Scope baseline
  • It provides information to
    • Activity list
    • Activity cost estimates
    • Project budget
    • Risk register
    • Accepted deliverables

What is the difference between a deliverable and activity?
A deliverable is the result or outcome of series of activities. The activity represents a small portion of the total work package and deliverable.

Why is WBS important?

  1. WBS is a hierarchical representation of the scope of a project; it represents the total scope of work required.
    • A WBS represents the total scope and hence it can act as a checklist for the project.
  2. A Project Manager can easily see the completed work and what is work remains in the project.
    • The deliverable represented by the WBS is easily monitored and tracked.
    • Each successive level of WBS provides a basis for more precise estimation of remaining effort, duration, resources and cost in which to complete the project.
  3. A WBS can serve as a template for future similar projects – specifically for repetitive processes thus making future projects easier and faster to plan.
  4. Activities are easily assigned to team members making accountability easier.

A WBS can reduce project risk.

Remember:

  1. A WBS uses nouns and adjectives to define work.
  2. The key is that we are talking about the nouns, the (mostly) tangible objects created through project work.
  3. Always put deliverables in the first couple of levels
  4. Only move from deliverables to tasks when you’ve pushed down several levels, and have gotten to packages that are reasonably small and estimable.
  5. The tasks to be performed are always in support of a deliverable.

Estimating Duration of Activities in your project

Estimating duration in a project is a daunting task that is usually a best guestimate based on past history. If everyone worked eight hours per day, which is usual in the U.S., but not in India (usually a 9 hour day), and they were 100% productive for all eight hours, you could calculate duration by taking the number of effort hours, divided by the number of resources. So, if one person is assigned a task activity that is estimated at 80 hours, and she works eight hours per day, the duration would be (80 hours / 8 hours per day) = 10 days. Similarly, if four people are assigned to the same task activity full time, the duration would be divided by 4 giving you 2.5 days (10 days/4 = 2.5 days).
However, no one really works a perfect 8 or 9 hours. Our work day is generally broken up into pieces in which other activities such as answering emails, lunch, meetings, other assigned activities, etc. A better estimate would use the 80-20 rule in which 20% of a resources time is eaten up by activities not related to the assigned work. Therefore, I would suggest using the following process to determine duration:
1. Estimate the productive hours per day
A rule of thumb I was taught is using a factor of 6.5 productive hours per day helps you take into consideration those other activities such as answering emails, lunch, meetings, other assigned activities, etc. Using the above example we find our answer for an activity estimated at 80 hours / 6.5 hours = 13 days for one resource, while four resources would take 3 days.
2. Determine the number of resources needed for each activity
Knowing that the more resources you apply to activities, the earlier you can complete the activities, obviously two resources may be able to finish an activity faster than one person, but it may not necessarily be twice as fast. At some point, additional resources will not make the activity finish any sooner, and could possibly, make it go longer.
3. Determine available workdays
You need to take into account holidays, vacations and training, especially when using international resources. This was not included in the example from number one above, since this non-project time can be scheduled and accounted for in advance. On a twelve-month project, team members will be out for vacation days, holidays (US and international) will need to be accounted for in your schedule. To make your schedule more accurate, take into account any days that you know your team will not be available to work on the project.
4. Determine resource time allocation
Account for any resources that are not full time. Keep in mind that a resource whose allocated only 50% of his time to your project will take twice as long to do any individual activity. Using our previous example, you have an activity that has an estimated effort of 80 hours, and you assign a resource that is only allocated 50% to your project, the resulting duration will be at least 25 days for one resource, if not more. For four resources our duration would be 7 days.
5. Calculate delays and lag-times
Some activities have a small number of effort hours, but a long duration. For instance, a deliverable approval may take one hour, but might take two weeks to schedule the meeting.
6. Determine constraints
When building your schedule, identify the tasks that need to be done sequentially and those that can be done in parallel. If you have enough resources, all of the parallel activities can be done in parallel, but only if you have the right resources available at the right time. You may have activities that can be be done in parallel, but you have only one resource to them, thus they have to be done sequentially.
7. Document assumptions
Most importantly, you will never know all the details of a project. As such, it is important to document all the assumptions you are making along with the estimate. The more you communicate with your stakeholders on how you arrived at your conclusions, the better able they will understand your plan and be more willing to accept it.

Using the above suggestions should help make estimating durations for your projects much easier.

Progressive Elaboration

Progressive elaboration can be defined as continuously improving and detailing a plan as more detail and specific information and more accurate estimates become available as the project progresses, and thereby producing more accurate and complete plans that result from successive iterations of the planning process.

So, what does that really mean. In practice it basically means that we don’t have enough information when we first start to plan a project to be able to reliably plan it out in detail. There are too many unknowns. There are too many unanswered questions. And we won’t be able to answer them until we get to that point in the project.

Every project is progressively elaborated. Think about it. A project is a temporary endeavor undertaken to create a unique product or service. It is a unique enterprise created to solve a problem or fulfill a need. By it’s very nature of having never been done before within the organization there will be many unknowns and unanswered questions.

Because of the uniqueness in every project, iteration becomes the rule. In my experience in software development projects, we knew from the get go that there would be lots of changes as we moved forward. Things change. In a nutshell: we had to be ready to accept change. What we initially thought would work one way turned out to be impractical. Something new would be created by an outside party that did a better job than what we had originally designed. In software or web development, change is the rule, not the exception.

So what do you do? Well here are some suggestions:

Be sure to communicate with all the team leaders and stakeholders if change becomes inevitable. Make them a part of process of determining what, how, where, and when that change will occur. Make sure they understand why it’s occurring.

Make sure you gather reactions to any change that needs to occur. Not gathering all feedback can be disastrous because that one piece of information you neglected to get could have been the deciding factor on whether change took affect.

Remember that change will not be readily accepted. Especially in companies where many of the employees have been doing the same thing for many years. They live by “If it ain’t broke, don’t fix it” attitude. They’re comfortable with the way things are. But most likely they’re really just afraid of the unknown, which is what your proposed change will bring, at least in their minds. Prepare for continual reporting of progress and delays so everyone knows how the change is advancing and what successes have been made. Be prepared to enforce these changes though, especially when some try to revert to old habits.

Be sure to create the means for people to express their thoughts and feelings. Be supportive, show empathy. By hearing people out and allowing them to participate in the development of the needed change you are allowing them ownership. You create buy in by the very people who are affected and need to accept this change. People who feel they have ownership in the process are more apt to want to see it succeed then those who don’t.

Most importantly, be sure to create a plan to handle this change using project management techniques, such as risk assessments, stakeholder analysis and progress measurements. But don’t be afraid of change, just be prepared for it.