Table of contents for Estimating Effort

1. Estimating Effort: Part 1
2. Estimating Effort: Part 2
3. Estimating Effort: Part 3

Preparing Three-Point Range Estimates

The mechanics of preparing three-point range estimates, particularly if you are working with team members who have never used the technique before, are important. And just a reminder: we are still dealing with effort estimates; duration estimates come later.

Working one-on-one. Let’s again start with a simple case where you need an effort estimate from an individual team member regarding how much of their effort is likely to be required to complete a specific activity. The first step is to make certain that both of you have a common understanding of words like “estimate” and “complete.” For example, it is always tempting to say something like “how long do you think this will take?” This question is likely to produce a duration estimate rather than an effort estimate. Try to ask something like “how many hours of your time do you think this activity will take?”

Begin the discussion with a review of the work to be done to ensure that both you and your team member have a common understanding of the work. If there are unknowns, decide how to handle them—make assumptions, go get answers, whatever.

Once you have a reasonable level of agreement, ask the individual for their effort estimate of the most likely result. I tend to use words like “if these assumptions turn out to be true, how much of your time do you think this work is likely to take?” After they’ve answered that question, I ask “if every thing goes well, if you get very lucky with this activity, and still using the same assumptions, how much of your effort do you think this activity will take?” Then I use similar language to obtain a pessimistic effort estimate.

Remember to keep your assumptions constant. If you develop an optimistic estimate based on everything going well, and a pessimistic estimate based on nothing going well, the range of the estimates will be quite large. Very large ranges make most people uncomfortable because it appears that they don’t understand the work. In addition, it will be harder for you to assess the accuracy of the range estimate later because you’ll have to factor in all the different assumptions.

Understand that the first few conversations with any given individual are unlikely to go smoothly. They may generate additional questions or ask you to make additional assumptions at any point during the conversation. Fine. Let them. Help them climb the learning curve. My experience is that it takes most people 3-5 iterations to get comfortable with the process. After that, they’ll start giving you three-point estimates automatically.

Feel free to challenge their estimates, but do so constructively by asking clarifying questions. Do not cast aspersions on their estimates. If your estimate differs from theirs by a substantial amount, the most likely explanation is that your understanding of the work differs from theirs. Concentrate on identifying and resolving those differences.

It also seems to be important to start by asking for the most likely result, then the optimistic, and then the pessimistic. I don’t know why, but this sequence seems to work best.

Working with a group. Most of your estimates will not be developed one-on-one, but rather will be developed by small groups as part of a team planning process. The basic process remains the same for these small groups:

• Review and agree on the work to be done.
• Document the assumptions.
• Develop three-point range estimates starting with the most likely result.

Even when some of the group members don’t have deep expertise in the project’s work, their presence can help to surface unstated assumptions and to build team-wide commitment to and understanding of the effort estimates.

Other approaches to three-point range estimates. Some project managers try to expedite the development of a three-point range estimate by asking for only two numbers—the most likely and some form of variance (e.g., “10 hours, plus or minus 2”). While this statement equates to a three-point range estimate of 8, 10, and 12, in my experience, it lacks the richness of my process—it doesn’t seem to generate the same degree of thoughtfulness from the estimator.

Will this take too much time?

I am convinced that the thinking process and the conversations that support three-point range estimating contribute to the development of more accurate estimates. Short-circuiting the process may appear to save time, but it’s a false economy.

My experience is that developing three-point estimates almost always takes less time than single-point estimates because the conversational process eliminates the posturing and gamesmanship that often delays the development of estimates. I’ve have had teams in my project management training courses spend less than an hour to develop an estimate for a 4,000 hour project — an estimate that later proved highly accurate. A recent client spent less than a day to discover that a mission-critical, multi-million dollar new product development project was going to be eight months late. An investment of something less than $10,000 is expected to return in excess of $10,000,000. Time spent estimating is not a cost, it is cheap insurance.

In the next article of this series, I’ll cover some of the more difficult challenges of estimating effort on projects: what to do when management thinks it should take fewer hours, using range estimates with project management software, how to deal with the natural (and normal) biases of the estimators, understanding the difference between accuracy and precision, and how to use some basic, simple statistical methods to create an estimate for the whole project.

Image via Wikipedia

…or another story of success.

Have you learned about the “Pyramid of Needs” by Maslow?  The last step is the stage of self actualization.

For 17 years I was working for a global player.  The last seven years I collected a lot of experience in international project work,  have setup a PMO and installed a project management information system with world network access.

Preconditions for the last stage. Still a certificate was missing and there was no question to decide for PMP® by PMI®.

Timetable:

• Oct 07: Kickoff
• Oct 07 - Dec 07: Reading PMBoK (slowly )
• Dec 07: Joined an one week PMP-prep-seminar
• Dec 07 - Jan 08 Selfstudying different PMP-lecture and answered thousands of questions to get used to the examination.
• Jan 28th 08 : Passed PMP-Examination with big smile.

Milestone reached !!

After some preparation I have founded Pyramid Projects in June 08.

I invite you to my website, where you also can find informations about project management

I like the sentence from Abraham Lincoln:

“The best way to predict your future is to create it!”

have fun in life and success on job,

Tom

If you’ve made it here, then you should understand what a departure these four tenets are, for most organizations,  from the way they’ve always managed solving technical problems. As we begin discussing SCRUM, I’ll be painting the picture from the standpoint of a business that is using a single small team doing internal, LOB application development. There are minor variations of this content for those producing commercial products,  and for instances where you might be a cog in a much larger machine, or performing non-appdev tasks like hardware, engineering, manfacturing, etc.. I hope to cover these scenarios in depth in future posts. That said, you need to understand that SCRUM lays out a few, simple roles:

1. A “Product Owner” [someone from "the business"] owns ultimate responsibility for the behaviors and functionality of the system as well as the schedule of what features will be delivered and when.
2. A “ScrumMaster” is responsible for removing any barriers - organizational, technical, inter-personal, etc. that are/might be preventing the team from delivering on it’s commitments.
3. A “Team” consists of everyone involved in delivery…that may include architects, developers, designers, business analysts, DBA’s, QA pros, and perhaps marketing, training developers, technical writers, etc. Popular guidance suggests that a team should consist of 5-9, although it can be larger or smaller, as always, you should really have a valid reason for doing it.

and a few ground rules:

1. All meetings are Time-Boxed.
2. Development is organized into fixed duration, completely encapusulated, development windows [typically 30 days] called a Sprint.
3. The Product Owner is responsible for collecting, capturing, prioritizing, and communicating the system requirements [called User Stories]
4. Each Sprint consists of four major meeetings…
   1. Sprint Planning Meeting #1 is used by the team to review the Product Backlog and discuss the desired outcome of the Sprint.
   2. Sprint Planning Meeting #2 is used by the team, having used the interim between the previous meeting to estimate the size of each item on the Product Backlog, to choose how many of the top items in the list can be completely delivered in the next 30 days. This subset of the Product Backlog is called the Sprint Backlog.
   3. The “Daily Standup” is a daily, 15-minute meeting used by the team to report progress since the last meeting, report what each person will be working on before the next meeting, and finally to indicate what, if any, impediments there are to their progress.
   4. The Retrospective meeting happens at the end of the Sprint and is intended as an opportunity for  the Team, ScrumMaster, and Product Owner to candidly discuss what went right and what went wrong during the Sprint, and then to discuss and assign specific actions in order to adapt the process for the next Sprint.
5. The “Team” is self-organizing and is responsible, as a unit, for understanding and delivering the product envisioned by the Product Owner.

Vertical Scrum - Flickr attribution license: jurvetson

So, now you should have a general feel for who’s involved in the effort and what each person’s responsibilities are.

Now, the first thing you need to do to understand SCRUM is to set aside your feelings and understanding of organizational structures, reporting structures, and anything else that smells of command and control. SCRUM requires a new organizational philosophy that typically manifests itself as a shift from the scenario where management controls production to one where the workers are empowered to innovate and the role of management is to alleviate anything that slows or prevents production. Naturally, worker bees are usually OK with this because they are positively affected and empowered by this shift, manager bees struggle with it because it takes their “power” away and expects them step into a role of “Servant-Leader”. If your ogranization [specifically management] can’t  adapt to this shift and you still try to “make” SCRUM work, you’re either going to have severe managerial attrition, failed projects across the board, or best case will be marginal successes with burned-out developers who feel caught in the middle/terrorized by the PM. You should also understand that SCRUM mandates very little, in fact, the SCRUM methodology is extremely lightweight and does not provide specific proscription for how you might implement it in your organization. The result of this has been mis-application of the principles and philosophies behind SCRUM, but more on that in a later blog post.

The second big mindshift you need to understand is the Agile approach to requirements. Contrary to the “waterfall” and “modified waterfall” approach to development, the collection of detailed requirements in SCRUM is deferred until the last moment. In a “traditional” or “waterfall” development process, the requirements are collected in detail at the beginning of the process, and then the development team goes off into a closet and works to deliver according to the Statement of Work.  In SCRUM, a User Story is a component of work and represents a reminder for the developer to have a detailed requirements collection conversation with the Product Owner regarding the specific piece of functionality. I’m sure that right now you’re saying “this can’t work”, “my developers are too lazy to do that”, and/or “what about architecture”, and a thousand other questions. I’ll address these in future blog posts as well [this things is already approaching book status]. The benefit and net result of this approach to requirements is that the “customer” [Product Owner] can change the “scope” of the project [by manipulating the Product Backlog] in the midst of the project. In truth, and practice, this type of “change” is actually encouraged as long as the change to the Product Backlog is not made to the Sprint Backlog [although this can also be accepted as long as the Product Owner chooses an item of comparable size that can be moved from the Sprint Backlog to the Product Backlog and that the item being removed is not already in progress]. Because SCRUM welcomes scope changes, the product that is ultimately delivered should be an exact match to the customer’s business requirement.

The first thing to do when implementing SCRUM is to evaluate your organization’s willingness, capacity, and commitment to making the change. Second, make the same assessment about your willingness to be an organizational change agent because whoever adopts SCRUM will have to be prepared to make a firm and consistent stand that you CAN, with some effort, produce a ballpark estimate of time and cost to deliver a project and you CANNOT produce a detailed cost and schedule estimate, Gantt Chart, Project Plan, and the plethora of other documentation that a traditional waterfall approach mandates. This is a particularly difficult concept to endorse when you’re accustomed to managers, customers, executives, etc. that demand to know the “Not To Exceed” costs and schedule up front. This “cannot” stems from the fact that, with a new team at least, you cannot estimate velocity [again, that'll be in the next post] and as such you cannot determine how many Sprints it will take to work through the complete Product Backlog.

SCRUM and Agile are not silver bullets, and adoption of them requires a serious and significant commitment from the organization to embrace change. It’s not for everyone, but for those that can embrace change, do believe that it’s better to deliver smaller functional bites of an application than to deliver a monolithic application, and are willing to turn their organizational structure on it’s ear….then you’re on the right path…please stay tuned for more.

Table of contents for Project Management Strategy

1. Linking Business Strategy to Project Strategy
2. Moving from Corporate Strategy to Project Strategy
3. A Theoretical Framework for Aligning Project Management with Business Strategy
4. Close the Gap between Projects and Strategy
5. Tying Performance Metrics to Business Strategy

In the previous article, “Close the Gap between Projects and Strategy”, Johnson discusses drawing the gap closer between projects and strategy. Now we explore an article by Breakthrough Performance Management, which is about tying performance metrics to business strategy.

Executive managers ask for reports that show performance measures. Technical or key performance indicators are often displayed using dashboards and scorecards as a means to evaluate the health of the strategic plan. The problem presented in this article is that most organizations have a disconnect between corporate strategy and day-to-day activities. Therefore, organizations can measure performance, but they can’t manage it.

Breakthrough Business Performance indicates that some attributes that lead to the failure of executing strategy are poor definition, non-tangible, not clearly communicated, and measurement not focused on key drivers. Organizations are invited to adopt a discipline that links strategy execution with key business processes through the management of 1) objectives, 2) initiatives, 3) resources, 4) risks, and 5) incentives. The theory is that organizations can manage performance by tying performance metrics, initiatives, resources, and risks to strategic objectives.

Some projects are required to use Earned Value Management (EVM) to manage performance on large scale high risk endeavors. EVM is a methodology used to integrate scope, schedule, and budget and uses objective performance measures to monitor progress. There are two types of effort that are measured, level of effort and discrete. Level of effort is often the administrative support such as general project management and other overhead type functions. Discrete effort involves the more tangible key drivers or objectives required for delivery at the end of the endeavor. A well designed earned value management system requires the responsible control account managers to clearly define the initiatives by depicting the particular objectives in a work breakdown structure dictionary. The dictionary will also house some of the high level risks or assumptions that may impact the outcome. The resources are presented in a basis of estimate artifact that explains the rationale behind the costs related to the initiatives. All of the appropriate scope, schedule, and cost artifacts are captured into one project management plan and performance measurement baseline as the basis for performance.

Using project management software tools such as Primavera P6, Deltek Cobra, and other enterprise systems have proven useful to organizations to obtain a more formal method of achieving best practices for measuring and managing performance. One caveat is that investing in a specialty tool sets also means that organizations must invest in specialty experts to operate and maintain the system. The trick is striking the right balance between measurements vs. management. Integration management just happens to be one of many hats that project managers wear throughout the life of a project

References

Breakthrough Performance Management: Tying Performance Metrics To Business Strategy.

(2005, January). Business Credit, Retrieved October 12, 2008, from EBSCO MegaFILE
database.

I recently obtained my CAPM with the help of Cheetah Learning’s 3 week online course. I was a little skeptical of by ability to succeed at a course that was online, as I had never taken one before, but I was pleasantly surprised by the course structure and the close interaction with my course instructor. Since obtaining my CAPM, I have received a raise, and more job responsibilities.

I chose Cheetah for my exam prep because of their well known name in the industry (awarded Provider of the Year by PMI), and because every Cheetah alumni I talked to had nothing but great things to say.

Just a quick note about how Cheetah helped me improve my career. You might call me a Cheetah Cheerleader now, but that is just how good the course was. I highly recommend the online course if you are pursuing your CAPM, and I am looking forward to taking their PMP Prep Course when I am ready to become a PMP.

Thanks PM students, and may the student in all of us continue to learn and pursue our goals in our Professional Project Management Careers.

Kristen Kent
kristenkent123@gmail.com

(If you have any questions about my experience as a CAPM, please feel free to write me!)

Image from PMI.org

I would also like to thank all the contributors to pmStudent for their willingness to share their own knowledge and expertise, stories of professional growth, and questions.  This is a vibrant community and I am so glad to be a part of it!

Reaching out to other people and asking for their advice has always been beneficial for me.  I ALWAYS learn something new.   Most of the time, I’m reaching out to someone who has experience and/or training in the specific area that I lack.

People new to a field who find a natural ability for it sometimes get an ego wayyyy before they’ve earned the right to have it.  Don’t let this happen to you.  Don’t be afraid to change your mind based on new information.  Seek out mentors, and LISTEN!  Forget your own preconceptions for a bit and take what they say to heart.  You’ll be amazed how much you can learn and grow.

Here is Glen’s post.  Click the images below for more on his recommendations.  Some link to a review, some to a place you can buy it if you wish.

Rita Mulcahy’s Hot Topics were exactly what I was looking for. The flashcards are about 4 inches by 6 inches, on a spiral bind. It makes the pages very easy to flip.

Of course, the important part is not so much the format as the content. Hot Topics is not a bunch of multiple-choice questions, but rather open-ended questions that help me acquire knowledge. I found the questions well focused. They helped me identify which knowledge areas need more review.

With its 600+ questions, Hot Topics is definitely a must-have study help for PMP and CAPM exams.

Karine is the pen behind Go Ahead, Manage, a blog about the life of a small company in the great world of project management software: from marketing to product management, software development… and project management, of course.

Table of contents for Project Management Strategy

1. Linking Business Strategy to Project Strategy
2. Moving from Corporate Strategy to Project Strategy
3. A Theoretical Framework for Aligning Project Management with Business Strategy
4. Close the Gap between Projects and Strategy
5. Tying Performance Metrics to Business Strategy

In the previous article, “A Theoretical Framework for Aligning Project Management with Business Strategy”, Milosevic and Srivannaboon implicate a framework for alignment to achieve a competitive advantage. The next review by Breakthrough Performance Management is an article about tying performance metrics to business strategy. Now we explore the gap between the organizational components and the project level components.

Johnson points to the research of Cathleen Benko and F. Warren McFarlan which established that $2.3 trillion are spent annually on projects by U.S. companies. A majority of companies are performing these projects without having a strategy that ties the project to the organizational needs. Benko and Mcfarlan conclude that companies must optimize their projects by using portfolio management that focuses on both the relationship of synergic projects and the alignment to corporate strategy.

The primary question that Johnson presents is, “How can companies surmount these obstacles so their projects collectively support the corporate strategy, achieve efficiencies, and position the company to adapt to the future?” The first approach is to view your projects through a “strategy lens” and the second approach is to build a project-portfolio “brain”. By keeping it simple and involving the right people, portfolio management systems allow executive management to look across their enterprise for duplicate efforts that chip away at the bottom line. The key for success is to have constant communication on multiple levels.

Consider the application of tying the project level structure and strategy of the resource loaded network (RLN) development activities to that of a contract procurement structure and strategy at the business unit level. The project lifecycle is 1) pre-award, 2) contract execution, and 3) contract close. During the pre-award phase, a request for proposal (RFP) follows a procurement timeline consisting of four sequential phases,1) receive draft RFP, 2) receive final RFP, 3) submit proposal, and 4) contract award. At the organizational level, procurement specialists are primarily concerned with capturing the contract and handing it off to the project. Project level stakeholders are also concerned with capturing the contract, but more focused on the implementation of the proposal strategy. The alignment of the organizational components to that of the project level components often determines the success of the project.

The business unit has a strategy to capture contracts that continue to grow the business in terms of revenue recognition and customer relations. Therefore, projects implement the contract proposal in a way that satisfies the customer requirements on schedule and on budget. Strategic managers can group projects into portfolios by taking into account some of these similarities relating to the customer such as, risk in terms of contract type, Integrated Master Plan/Integrated Master Schedule RLN development, Earned Value Management, and so on. Processes, procedures, methodologies, and other continuous improvement activities are captured at the portfolio tier with a direct relationship to the customer requirements. Portfolio management assists in closing the gap between projects and strategy by utilizing an enterprise project structure and strategy that links the hierarchy of the organization to that of the project. Strategic managers can use portfolio management to achieve their projects collectively as they support the corporate strategy, achieve efficiencies, and position the company to adapt to the future.

References

Johnson, L. (2004, June). Close the gap between projects and strategy. Harvard Management

9(6), 3-5. Retrieved October 12, 2008, from EBSCO MegaFILE database.

• Many questions involved picking the “best” of several correct answers
• The technique of eliminating 2 answers first didn’t work in some cases…for many there were 3 correct answers to choose the “best” one from
• I don’t remember any questions that involved picking which answer is NOT correct
• There was a calculator program built into the CBT software, was not allowed to bring in my own calculator (it may be different for you, I suggest you check with your examination place beforehand)
• I brought bottled water and some light snacks, and took a break at least every 45 minutes.  It was good to just stare out the window and clear my mind of PMP-related thoughts for 5-10 minutes.
• It took me only 2 1/2 hours, but I could see how if you are not a native english-speaker it may take longer to interpret the questions properly.

My preparation:

• PM Prepcast (comes with some sample questions, study guide, etc.)
• PMBoK Guide (reference only, I never read through it)
• Using the concepts whenever possible on my project
• 2 weeks before the test, no more studying.  Only sample questions.  All the free sample questions I could find plus the ones I got with the PM Prepcast

I listened to the PM Prepcast on drives to and from work, and because he gives so many examples of real-world situations it helped me “internalize” the concepts so I really understood them.  I didn’t spend any time trying to memorize inputs and outputs, etc.  If there was something I needed to see, I made a mental note and then when I got to work or home I’d pull out the PMBoK guide and reference the section in question to better understand it.  For the most part, I just used the graphics and flowcharts in the PMBok guide for reference.

What value did I get out of it?

My oldest son Mazaryk and I

The primary reason I did the PMP was so I can have it on my resume and not get it thrown in the trash before a potential employer even talks to me.  The PMBoK is a standard, not best practices.  It’s a framework, not a methodology for how you should actually manage a project.  I know some have said that some firms actually screen out people if they have a PMP certification.  That is a very small number indeed, and truthfully I wouldn’t want to work with them anyway.  If someone ASSUMES incompetence on the basis of having earned a certification, then they are more consumed with their own ideological stance on the matter than hiring a qualified candidate.

No, the majority of employers who know anything about what the PMP is are screening for it, not against it.  Therefore, it is important to me from a pragmatic standpoint that I put myself in a position to best support my family with the value I bring to the firms I work with.  The PMP is but one of many things I’ve done and continue to do in order to market my skills and value effectively.  I understand that this certification does not certify me as a project manager, nor does it certify any level of competency.  I think it’s a signal that I have a minimum level of knowledge about project management and have some familiarity with formal practices laid out in the PMBoK standard.

Now, the primary benefit I’ve received was NOT as a result of earning the certification.  It was during the process of studying for it and applying the concepts in my day job, alongside other frameworks and methodologies and specific processes necessary for my project’s situation.  When I wrote a management plan that was not in line with the PMBoK, I understood exactly how and why, and that there’s nothing wrong with that.  I can’t stress enough the value I received from the PM Prepcast.  I paid less than $50 for it, and it was worth at least $500 to me.  It was so much better than any boot camp, training class, or prep book.  Those things mostly focus on memorization or take a lot of time and money.  I studied while I was driving and got lots of real-world examples to bring the concepts to life.  I’m confident that if I took the PMP exam again a year from now, I’d pass it with no problem because I know this stuff, I didn’t just memorize it.

Next up, the IPMA/asapm certification.

Table of contents for Estimating Effort

1. Estimating Effort: Part 1
2. Estimating Effort: Part 2
3. Estimating Effort: Part 3

This is the second in a series of articles on estimating effort. In the first, I focused on definitions since I find that many people use terms such as estimate and budget as synonyms when, in fact, they are very different. Here is a brief recap of the key definitions that I will use:

Estimate. An informed assessment of an uncertain event. Informed means that you have an identified basis for the estimate. Uncertain recognizes that different outcomes are possible.

Effort. Effort is an expenditure of physical or mental effort on the part of a project team member. Effort is normally measured in terms of staff hours.

Budget. A management metric that uses the effort estimate as one of the key inputs.

Baseline. A time-phased budget that has received all necessary approvals.

What are you estimating??Let?s start with a fairly simple example to build a conceptual foundation.?It may seem obvious, but the first requirement for developing an estimate is to know what you are estimating. For now, let?s assume that you have been asked to estimate how much effort (how much of your time) is likely to be required to paint your bedroom. Although this is a fairly small activity, it is still one with a significant amount of uncertainty:

• Do you have to paint the ceiling and the woodwork, or just the walls?
• Are there windows to be painted? Do they have mullions?
• Is there furniture in the room? Can it be moved? If it can be moved, is moving it out and back in part of ?painting the room??
• Is choosing the color part of this activity? What about going to the store to buy the paint?
• How many coats are needed? Is there any special finishing involved (like marbleizing)?
• Will anyone be helping you? Or will you be doing all of the work yourself?

If you don?t know the answers to these questions, you have a couple of choices:

• You can decline to prepare an estimate at all.
• You can prepare an estimate that allows for a large amount of uncertainty.
• You can make some assumptions about the answers to these questions and estimate based on those assumptions.
• You can try to reduce the uncertainty by getting answers to the questions before preparing an estimate.

Any of these approaches is acceptable as long as your stakeholders know which approach you are using!?Most of the time, you will use some combination of approaches. You will make some reasonable assumptions (and you will always document all of your assumptions!). You will ask some questions. Then you will apply your best judgment.

Range estimates.?You can improve the usefulness of your effort estimates by making range estimates. How does a range estimate work? In its simplest form, you estimate a low value and a high value for the amount of effort that you think you are likely to need. For example, in the case of painting your bedroom, and assuming that the work is limited to applying paint to the walls, you might estimate 2-3 hours.

The fundamental concept behind range estimating is that you don?t need to know the exact amount of effort that will be required. You do need to know that it isn?t going to take a full day out of your schedule. You do need to know that this isn?t a trivial activity that can be completed in a few minutes. As long as the actual result is somewhere between 2 and 3 hours, you have made a good estimate.

Even if the actual result falls outside of that range, you still made a good estimate since it was the best estimate that you could make given what you knew at the time. In addition, you can learn from any?variance (an actual result that falls outside the predicted range) and use that information to try to improve your future estimates.

Using range estimates takes much of the pain out of the estimating process. If you are accustomed to single point estimates, it can be very difficult to choose between 2 hours and 3 hours. Even proposing a single-point estimate of 2.5 hours can be difficult because you know that it might take more or less than that amount. Using range estimates allows you to estimate even in the face of uncertainty.?If your boss insists on a single point estimate, he or she is most likely looking for a budget, not an estimate. There?s no problem with giving them a single number as a budget, but you really should share your estimate with them as well so that they will understand how much or how little uncertainty is involved.

Three-point range estimates.?You can improve the?usefulness?of your effort estimates still further by making three-point range estimates. In addition to the high and low values of a simple range estimate, you add an assessment of the most likely in-between result.

Let?s say, for example, that you are living in the world of Groundhog Day such that you can paint your room 100 times and keep records of how much effort it actually took. You discover that you never spent less than 2 hours and never more than 5. You also discover that your actual results produce a triangular distribution with a peak at 3 hours as shown below:

Based on the availability of this actual, historical information, you would estimate the amount of effort required to paint a similarly sized bedroom as follows:

• Most likely: 3 hours
• Optimistic: 2 hours
• Pessimistic: 5 hours

I understand that you will seldom if ever have such wonderful, perfect historical information to base your estimates on, but the great thing about range estimating is that you don?t need perfect data! As long as the three-point range estimate is reasonable, errors in the effort estimates for individual activities are likely to balance out over the course of the project.

Even in this case, even with perfect data, you still don?t know how exactly how much effort will be required for the next bedroom that you paint. It might be 2.5 hours; it might be 3.75 hours. Doesn?t matter. What is important is that you have effort estimates that are reasonable; that you have effort estimates that will allow you to manage your project more effectively.

Next: preparing three-point range estimates

Table of contents for Opportunity Management

1. The Need for a New Knowledge Area
2. The Case for Opportunity Management
3. Effective Opportunity Management for Projects

Glen Alleman left a comment recommending several resources for me, one of which is the book “Effective Opportunity Management for Projects“.  I am reading it now and would like to share some of my initial insights thus far.

I’ve found the authors agree with me that standard risk management approaches mostly pay lip service to opportunity management without really addressing it.  In correlation (not necessarily causation) with that, most project managers and teams focus on threats as the primary target of risk management.

I’ve also revised my view of needing a seperate knowledge area for opportunity management.  Through the various articles, websites, and books I’ve reviewed thus far I believe it should be handled within risk management; but risk management approaches and project managers need to do more than just pay opportunity management the lip service they do today.

A citation from the book which states my view nicely:

“….both can be handled by the same process, although some modifications may be required to the standard risk management approach to enable it to deal effectively with opportunities.”

Another important insight is that opportunities are not merely the mirror-image of threats.  A chance that a threat will not occur is NOT an opportunity.

“Distinctive opportunities exist in their own right, presenting the chance to enhance project objectives, deliver early, cost less, increase customer satisfaction, improve competitiveness, enhance company reputation, etc.”

Thanks for tagging along with me on my journey through better understanding opportunity management.  More to come!

An emerging global business culture has brought with it an ever-expanding language of ‘project-speak’ that you hear in boardrooms around the world. My advice is to learn the lingo in your field as quickly as possible to maintain your competitive edge.

The more diverse the field, the more terms are needed to operate within it. With over three decades of experience with project managers from Shanghai to Stuttgart to Salt Lake City, I have witnessed an explosion of new terminology in project management first-hand (from just over 1,600 terms in the 90’s to over 3,400 today). As globalization broadens markets, the language required to keep up grows with it. What you say is as important as how you say it.

Let’s take the term ‘drill down’. In the oil industry, you might think it refers to the act of seeking oil under the Earth’s surface. In project-speak, it actually means the act of moving from a summarized view of data into a lower level of detail. While on an oil rig in the North Sea, you would want to know the difference.

Or consider ‘unk-unks’. No, it’s not a Bali starling mating call, but a risk management term that stands for unknown unknowns (risks that are unknowable). ‘Pound of flesh’ is another favorite, eliciting scenes from your favorite horror movie. In project management, however, it really means you’re going to have to pay someone back in a huge way for doing something for you. Aside from the obvious hard skills, language is key in project management. After all, projects are people.

There exists an international business culture that has emerged as a result of globalization and cross-border and cross-functional project activity. Managers worldwide tend to be a highly educated, well-credentialed body of professionals who are apt to read the same business books and who listen to the same lecturers and pundits on various topics. It’s best to learn the language so, when you attend meetings, collaborate on projects or are involved in any business activity, you understand what people are saying. And, perhaps more importantly, when it’s your turn to speak up, they understand you, too.

Table of contents for Project Management Strategy

1. Linking Business Strategy to Project Strategy
2. Moving from Corporate Strategy to Project Strategy
3. A Theoretical Framework for Aligning Project Management with Business Strategy
4. Close the Gap between Projects and Strategy
5. Tying Performance Metrics to Business Strategy

In the previous article, “Moving from Corporate Strategy to Project Strategy”, Morris and Jamison expand on the idea of moving strategy from the corporate level to the project level. The next review analyzes an article authored by Milosevic and Srivannaboon who support this movement of strategy through their framework for alignment between these levels.

Business strategy is summarized as a means of creating competitive advantages to achieve sustainability while attracting customers and defending against competitive forces. A generic business strategy typology developed by Porter is used to establish the foundation for evaluating the alignment between project management and business strategy. Porter’s generic strategies are cost leadership, differentiation, and focus. Porter proclaims that firms can achieve a competitive advantage by choosing one of these strategies. However, firms are compelled to focus on a combination of strategies in reaction to global competition. This is termed as the best-cost strategy. Milosevic and Srivannaboon use cost leadership, differentiation, and best cost as the primary business strategies of the analysis. The authors also point to Shenhar’s strategic project leadership framework elements which consist of strategy, organization, process, tools, metrics, and culture.

The authors infer that the competitive attributes of the business strategy drive the focus and content of the project management elements. A pattern revealed through research indicates that organizations can align projects with business strategies into three levels: the strategic, the tactical, and the corrective emergent strategic feedback. Level 1 (the mediating process at the strategic level) is the beginning of the alignment process. At this level strategic managers derive the intended strategy and typically used portfolio management to determine the right projects that would contribute to the organization’s goals. Level 2 (the mediating process at the project level) involves delineating additional detail for the projects selected during Level 1 interactions as a means to ensure proper alignment with the project life cycle. The project life cycle is classified as the planning process and the monitoring process. At this level project managers develop a project management plan that ties back to the business goals and objectives. Level 3 (the mediating process at the emergent strategic feedback level) uses stage gates or milestone reviews to evaluate the project status on scope, schedule, and budget. As the project is executed, emergent actions occur that may change the intended strategy. This level ensures feedback from the project level as a means to allow the business strategy to adapt to its competitive attributes brought on by change. The authors therefore conclude that a combination of intended and emergent strategies is needed to align project management and business strategy.

One can infer that once strategic managers have selected a business strategy with the intention of sustaining the organization that portfolio management can assist in the decision making efforts of selecting the right projects that will contribute to the organizational needs. Also, a standard project lifecycle is needed for aligning the business strategy and the project management elements. Projects organized into portfolios that utilize best practices, common methodologies, and continuous improvement will determine the success of implementing the business strategy. The feedback loop, i.e. stage gates, will make sure that resources are funneled appropriately and non-performing projects are terminated efficiently and effectively. Emergent strategy often occurs as change on projects is inevitable. The strategic feedback provided from the project to the strategic business unit is critical for adapting the strategy transpiring through the mediating processes. Initially aligning the business strategy to the project is one thing, closing the gap between projects and strategy is a whole other story.

References

Milosevic, D., & Srivannaboon, S. (2006, August). A theoretical framework for aligning project

management with business strategy. Project Management Journal, 37(3), 98-110.

Retrieved October 12, 2008, from EBSCO MegaFILE database.

Table of contents for Estimating Effort

1. Estimating Effort: Part 1
2. Estimating Effort: Part 2
3. Estimating Effort: Part 3

This series of articles is extracted from a similar series I wrote for Projects@Work a couple of years ago. I’m posting it here in reaction to my review of Josh’s articles on Earned Value where he (in my opinion) used the term “estimate” when he should have said  ”budget.” Many of the terms related to estimating are used either inconsistently or imprecisely. Future items will address some “how tos,” but first, let’s take a minute to establish some common terminology.

Estimate. An estimate is an informed assessment of an uncertain event. Informed means that you have an identified basis for the estimate. Uncertain recognizes that multiple outcomes are possible. For example, if I tell you that there are two people standing outside the door, that one is male and the other female, and that one is 6’ 6” (200 cm) tall and the other is 5’ 2” (158 cm) tall, which would you guess is the female?

Most people will predict that the tall person is male. Most people will make an informed assessment of this uncertain event based on their knowledge that men tend to be taller than women, that few women are as tall a 6’ 6”, and that few men are as short as 5’ 2”. But what if I said the woman was a professional basketball player and the man was a jockey? Most people will now predict that the tall person is female.

Guess. A guess is a special kind of estimate—one where we do not have enough information to make an informed assessment. Note that in the above examples I used predict rather than guess since you do have enough information to make an informed assessment. For example, if I asked you to predict which person outside the door was taller, the person on the right or the one on the left, you would be forced to guess. In my experience, it is rarely necessary to make a true guess when working on a project.

Effort. Effort is an expenditure of physical or mental effort on the part of a project team member. We almost always measure effort in terms of staff hours. In many application areas (IT, NPD, pharma, consulting, architecture), most project estimates will be effort estimates. If you purchase resources from outside your organization, you may not see the effort estimates that were used to develop the cost estimates, but they’re there somewhere.

Cost. Cost is a measure of resource usage—employees and contractors must be paid, equipment must be bought or rented, and so on. Cost is usually expressed in monetary terms (dollars, euros, renminbi, etc.), but it can also be expressed in terms of hours of effort. One advantage of using monetary units instead of effort hours is that it should make comparisons between projects or among activities on the same project easier.

Another advantage of using monetary units to express cost is that the financial people in your company understand the language of money. One disadvantage is that monetary units can distort the numbers if the hourly rates are not reasonable. For example, if you use a rate of $100 per hour for an employee making $50,000 per year, and the same rate for someone making $150,000 per year, your cost estimates will misrepresent the actual cost of any project that has a preponderance of effort from one or the other.

Price. A price is what you charge someone for something. Prices are always (well, almost always) expressed in monetary units. Prices can reflect rates (e.g., $100 per hour) or totals ($500,000 for the entire project). Pricing is a business decision. It is usually derived from the estimate, but the estimate is not the price—if we are selling products or services to someone, we can charge more or less than our estimated costs. Even if we know for certain what the costs are or will be, we can still charge a different price.

For this series of articles, I’m going to assume that most readers are either managing internal projects or developing estimates in order to support a pricing decision that will be made by someone else (as is often the case for project managers working for a consulting firm). As a result, I am not going to cover pricing past the point of defining it.

Budget. A budget is a management control or metric (I prefer the term metric since control has negative connotations to some). A budget is a type of plan. Most people use the term only with regard to monetary metrics, but you can have effort budgets or schedule budgets as well. Project budgets should be derived from the project estimates.

Project budgets are not absolutes! Or at least they shouldn’t be. If a project is budgeted for $1,000,000, all of the stakeholders should understand that that number is a target. It is what the team expects to spend based upon what it knows today. If the team can find a way to spend less and still deliver the full scope, it should do that. If it needs to spend more, that should generate a discussion with the funders to decide what to do.

The project budget is not the same as the project price, even for a project done under contract. The seller can price the work for an amount that is different from its internal management metric.

Baseline. A baseline is very nearly a synonym for budget. There are two subtle differences. First, project baselines are normally time-phased. While I might say that the budget for my project is $500,000, I wouldn’t really have a baseline unless I had also defined when I expected to spend that money—how much in week 1, week 2, and so on. Second, the term baseline implies some level of formal approval. I can prepare a budget for