Articles (576)

0

Wednesday, 16 November 2011 09:45

PMs and Hockey Players

Written by

My son’s hockey team won a tournament recently that included a series of hard-fought, well-earned victories.  As the athletes came into the lobby from the locker room, everyone cheered, recognizing each individual contribution.  Another mom made a comment out loud that many of us hockey parents think just about every time we see them come out of the locker room: “They’re so little!”

It’s truly amazing to see 9-year-olds play hockey at the level that this team plays.  They skate on the ice as though they’re dancing on pavement.  They handle a stick with astounding skill.  They move the puck up and down the ice with agility that sometimes takes my breath away. 

Wednesday, 16 November 2011 09:33

What’s Done is Done: User Stories

Written by

Sept20thFEATUREThe definition of done is a fairly popular (and sometimes emotional) topic in the Agileverse.  It seems everyone has an opinion on the matter ranging from “It depends,” to “Let the teams decide,” to a meticulously designed set of business rules and criteria that account for every possible scenario.  However, as organizations adopt Agile practices (and specifically, Scrum), they seek to leverage guidance from those of us who have already blazed the trail.  Why then is this such a complex topic?

One aspect is that the word “done” is overused.  We must distinguish between different contexts of "done."  There is "done" at the story level, epic level, release level, product level, etc.  Each of those meanings of "done" has different criteria.   For the purposes of this article, we are only going to look at the done criteria for a user story.

Another aspect of the problem with done is perspective.  The word "done" is often used to mean "complete," as in a Scrum team saying, “We are DONE with this story." It's also used to indicate acceptance, as in a product owner saying, "This story is done." I typically teach and coach it this way: Don't say “done.”  Instead, use “complete” and “accepted” for more specific indications of status.  This gives way to defining completion criteria and acceptance criteria (Figure 1). 

thumb_dan20th1

 

Click to expand image.

Figure 1.  Done Criteria = Completion Criteria + Acceptance Criteria

The criteria for completion are summarized as follows:

  • “Code complete” – as defined by the organization/teams
  • “Unit tested” – as defined by the organization/teams
  • “Peer reviewed” – as defined by the organization/teams
  • “QA complete” – as defined by the organization/teams
  • Documented (as needed; determined by the Scrum team through tasking at the beginning of sprint)

The Scrum team determines when the completion criteria have been met with the guidance of the Scrum master.  At that point, the story is considered “complete.”

The criteria for acceptance are summarized as follows:

  • The list of expectations for a specific user story as defined by the product owner prior to the beginning of a sprint.
  • The product owner may define these alone or with the help of the Scrum team and/or Scrum master.
  • For cases where acceptance criteria are not clear, a spike user story will be used to define the problem and acceptance criteria for a user story to be completed in a future sprint.
  • The Scrum team must agree to these acceptance criteria at the sprint planning meeting.
  • Minor changes to the acceptance criteria once the sprint is underway are acceptable as long as there is formal agreement between the Scrum team, Scrum master, and product owner
  • When the Scrum team believes these acceptance criteria have been met, the user story is ready for a product owner review (demo), which occurs throughout the sprint
  • The review (Demo) of each user story should NOT be left until the very end of the sprint

The product owner determines when these acceptance criteria have been met.  At that point, the user story is considered “accepted.”

This approach provides a framework that is modular and can be adaptable around the definitions of “code complete,” etc. but clearly delineates the roles and responsibilities associated with delivering and finalizing work.  If a particular organization is striving toward 100% automation of functional tests that become part of a holistic regression test suite, then “creating automated test scripts” would be expressed in the QA complete criteria.

Further, one group might agree on what “peer reviewed” means but not the “QA complete” criteria.  Using this modular definition, each group can customize these definitions to suit their team’s specifications.

As part of this exercise of defining “done,” I have also identified in the following diagram (Figure 2) the different stages at which events occur in terms of the definition of done:

thumb_dan20th2

 

Click to expand image.

Figure 2.  Definition of Done Process Mapping

The first column defines the event or phase during which the activity in the second column takes place.  Column three shows who is responsible for the action item in column 2.  In one of the teams I am coaching, there was a highly contentious relationship between the product owner and Scrum team, and this diagram helped sort through who was responsible for what and when.  This, along with a well-defined definition of “done,” set expectations and the conflict was neutralized.

Each organization (and team) must come to a consensus on what the definition of done is for their particular projects/products at various levels (story, sprint, release, etc.)  In the next installment of this series, I will explore what the definition of done is at the sprint level.

Don't forget to leave your comments below.


Daniel James Gullo, PMP. CSP, CSM of Trinacria Consulting is a proven leader in the field of Information Technology and Information Systems who advocates and evangelizes best practices and quality for projects in all areas of business.  Specializes in delivering software development and testing projects which are on-time, under-budget, and high-value. A professional with demonstrated success in Agile and traditional project / program management, business analysis, quality assurance, and consulting services.  A highly praised and recommended consultant with an extensive history of satisfied customers and clients.  Fiscally minded with both local and global experience.  Open to travel both domestically and internationally.  Effectively manages teams and resources around the globe both on-site and remotely.

Project managers have the immense task of juggling requirements and resources that are often not under their direct control in order to produce the required project deliverables within the limited constraints to which they must adhere (scope, time, quality, etc.). Even if the perfect project plan could be designed and executed, it would not remove all of the risks that could ultimately impact a project. Plans must inevitably change for one reason or another.

Wednesday, 09 November 2011 10:34

Project Management Tips and Tools

Written by

Successful project management abides by several principles. Essentially, every project needs three components to be successful: it must come in on time, within budget, and to the degree of quality that is expected. Sounds easy enough, but every experienced project manager knows that anyone who counts their proverbial chickens before they hatch will not complete the project on time, budget, or with quality.

Successful project management has tended to rely on time-tested and proven methods of planning, managing, and charting workflow throughout the project cycle. The old saying, “When it’s not broken, why fix it?” can certainly be applied here; however, what if a new way of managing the workflow in a project cycle was more efficient, more accessible and more transparent to all members of the team?

Wednesday, 02 November 2011 09:29

Why You Should Align Your Project and Company Goals

Written by

Each year, as project managers we take courses and read articles and books on how to improve our project management skills: how to track the critical path, influence without authority, tackle bigger scope and bigger budgets, work with remote teams, flush out the ‘right’ requirements, engage the teams we’ll need for success and many other topics. Often, these are great courses and articles with great tips and advice that we use every day to deliver projects assigned to us. One area where PMs aren’t always included—or do not involve themselves in—is the project selection process, that pre-initiation stage where the project is still a concept, someone’s brainstorm or someone’s personal pet project.

Part II: The Solution and Its Value

Viewing Cyber Security as a Business Solution

As a continuation of Part I, although advancements in technology have enabled organizational strategies they came with a price to pay given the rise in cyber breaches.  Cyber security continues to be a moving target with no final technological solution insight. Considering the rate of progress in new technologies and their social prevalence, solutions are now more dependent on a person’s mindset, critical thinking abilities, and an increase in individual responsibility. These facts lead us to believe that the most effective resistance against cyber threats must now be built on shifting an individual’s mindset, adjusting human behavior and evolving legacy methodologies. Cyber security has elevated to become a required attribute for successful organizations and career professionals going forward.  Cyber safe practices require a proactive approach in addressing a new generation of cyber breach challenges associated with strategic asset delivery and survivability. The first step project managers should take is to make cyber security a priority and position cyber safe practices as part of the solution in the upfront initiation and planning processes. Project managers and delivery team professionals such as business analysts should also incorporate cyber security practices into the remaining project phases to ensure traceability of established cyber security requirements.

Wednesday, 26 October 2011 09:35

Got Projects Going Over Budget?

Written by

FEATUREOct26thYou’re not alone. Project cost overruns are common.

Statistics will tell you that over 85% of projects go over budget. But why? What are the mechanics behind project cost overruns and project schedule delays? Plenty of talented and experienced professionals engage in dialog about this very topic every day, and try to arrive at conclusions about how to stop projects from going over budget. In this article, I’d like to shed some light on the underlying workings as to the root causes of cost overruns and schedule delays. In order to tackle the problem of how to eliminate overruns, it’s important to understand the main reasons why they happen.

Obviously, there’s no one-sentence answer to these questions since every project is unique and the influences that trigger overruns can vary tremendously.

Luckily, however, there’s been quite a bit of research and experimentation around this exact problem — since it is a pervasive issue that so many businesses, large and small, struggle with. As a result, there have emerged some key factors we can point to that are the major contributors to projects going over budget and suffering schedule delays.

A lot of project managers and business owners have their own theories; and after a good deal of listening and reading, many will have you believe that it all comes down to one thing: Project Changes. Technically speaking, project changes are arguably the biggest contributor to projects going over budget and blowing schedule deadlines, but for the purposes of this discussion, let’s leave Change and Change Management out of it. I’m saying that because I don’t believe changes are truly the root cause of cost overruns. I believe that if you approach a project anticipating that things will change throughout the project — and you have good mechanisms and methodology to track and account for change — Project Changes aren’t really the root of the problem and should not result in a project cost overrun. (Click here to read about making the best of Project Change).

Let me repeat that another way:
Project Changes may alter the original budget and schedule, however, if you have appropriate tracking and change-management processes in place, they shouldn’t result in a project cost overrun. They’ll just shift the size and duration of the project.

That’s all fine in theory, of course, and I know that in reality nothing works quite that smoothly; but rarely does anything in a project work as smoothly as originally planned. The changes and addendums that get added and removed to a project should be viewed as merely extensions of the original plan. Therefore, your ability to handle change management is directly related to your ability to plan and negotiate on the fly. So, yes, if you can’t do this very well, it’s going to lead to some serious cost overrun and schedule delays. My take on it is that if you’re ok with looking at it that way, it’s truly the controls, planning and estimating pieces that are the root of the change-management dilemma.

So, leaving Change out of the equation, what then causes project cost overruns and schedule delays?
First, it’s key to understand that cost overruns and delays don’t just suddenly happen: they in fact happen all the time, every day in every phase, mostly in small incremental chunks. They happen in Planning, Execution, Close-out and Reflection phases along with every stage within those. To get to the bottom of why, let’s look at the four major triggers for cost overruns and schedule delays, which I’ll explain in more detail further below:

1. Inaccurate Estimates

2. A lack of real-time visibility and control

3. Poor methods to determine project progress

4. Insufficient historical information

These four items relate directly to the major phases of a typical project: Planning, Execution, Close-out and Reflection.

Project Planning

So, let’s talk about the first one, Accurate Estimating. This is probably the most obvious culprit since if you’re running a $10-million project that was estimated to be a $7-million project, well you’re pretty likely screwed to come in on budget and on schedule. Overly optimistic estimates and those done in a hurry are common. Project estimators that rely a little too much on gut-feel without documenting and qualifying their numbers can also cause estimating snags. I’m a believer in gut-feel, by the way — my only qualifier on that is with the communication and transparency around quantifying where those gut-feel numbers come from. I’ll get to that more when discussing the value of good historical information.

Project Execution

The second item, real-time control, is easily the most insidious of the four. It’s all about having accurate, up-to-date information about what’s going on in the project. Of course, part of this control thing is covered by the old-school methodology of being physically present on the job-site. The even bigger control factor, however, really boils down to project tracking. When you track all your labor, equipment, materials, subcontractors, suppliers, etc., you’re able to view daily reports on everything that’s happening on your project. You’re empowered with a wealth of information, which is the ultimate key to ‘control.’ You don’t have to wait until the end of the month to find out what happened weeks ago and that currency of information becomes the critical element of managing successful projects. Here’s an interesting fact: when something goes wrong on a project, the size of the impact it will have on cost and schedule is exponentially related to how fast you can apply corrective action. In other words, every day that goes by without fixing a problem that’s occurred on a project will accelerate the budget impact.
I hate to say it, but real-time control is also about keeping your suppliers and subcontractors honest. If you don’t have a good tracking and control system in place, getting over-charged and double-invoiced is going to be a huge contributor to project cost overruns.
The third item, determining Project Progress, is also a nasty contributor to cost overruns during the execution phase. If you don’t constantly take the pulse of where you’re at with your project, how can you possibly know if you’re on budget or on schedule? You may have spent 50% of your budget, but if you’re only 30% complete, you might have a pretty big problem. The earlier you can find out that you’re facing a potential cost overrun in your project, the more chance you’re going to have to correct it.

Project Close-Out

Having agreed-upon project progress milestones and sign-off is absolutely vital to being able to control costs and get paid. This is partly covered early on during the planning and negotiation phases when you’re defining what it means to be finished, but it obviously has to also be viewed as a continuous evaluation during the life of the project. Being able to seamlessly close-out a phase, level, task and the project as a whole enables you to stop spending money and squandering valuable time. You need to do regular forecasts on your project to get a financial and schedule picture of how far along the project is, and whether you’re ready to achieve closure on any piece of the project. Again, I know this all sounds great in theory; but the thing is, if you don’t do it, that’s where the insidious overruns creep gradually and dangerously into your projects.

Project Reflection

Looking back on a completed project (or even a partially completed project) to examine where things went well and where things didn’t go so well is an indispensable part of running consistently successful, profitable projects. Otherwise, you’re doomed to repeat the same mistakes over and over. A project retrospective is more than just having a big group-hug with your team and your subcontractors (although, a little love-collateral can help keep the peace and smooth any hiccups). A reflection is also about examining the numbers, and using that information to feed future projects. First, however, you need to actually have those numbers — and the metrics, and the reports — and this means you need to have executed on project tracking and earned value management during the execution phases of your project.
Insufficient historical information plagues many businesses trying to run profitable projects. Sadly, it’s often the case that very little data is collected during a project, so very little is known about what happened. All that’s typically available to many project managers is the summary totals contained in the corporate ERP. This is only marginally helpful, as it’s missing so many crucial details that help planners and estimators get better at their job. Equally tragic is when information is tracked, but it’s stored in a series of spreadsheets. As we all know, the reporting and metrics you can achieve from spreadsheets is terse, vague and time-consuming to obtain.

We’ll talk more about this in upcoming articles. I hope this has been helpful. Please leave a comment and let me know what you think!

Don't forget to leave your comments below.


Chris Ronak draws from over 20 years working with project-based businesses in management, project management and consulting positions. He is currently the CEO and founder of 4castplus, a web-based software solution that delivers full project cost management, estimating, forecasting and real-time tracking to keep complex projects on budget and on schedule.

Wednesday, 19 October 2011 11:32

The Perfect Partnership

Written by

Companies often struggle to maintain a good balance between their market activities and their product development efforts. The fact is – most new products are not ready for prime time. This circumstance leads to products that deliver less value than anticipated or fail altogether. This inability of organizations to effectively bring products to market often creates a significant drag on companies’ ability to innovate and compete in today’s rapidly changing marketplaces.

There are a significant number of reasons why it’s so challenging to effectively bring products to market.  Some are external, such as changing market conditions or shifting customer needs. However, many problems result from internal challenges such as overstretched contributors, the wrong mix of skills, poorly understood processes, and misalignment between the core team members in the value creation process.

Professions such as business analysis and project management have boundaries and roles that are well understood. Both have their bodies of knowledge, process groups, and foundational knowledge areas.  In contrast and ironically, the product management profession spans 70 years but has yet to fully codify its body of knowledge. The resulting lack of clarity on the responsibilities and boundaries of a product manager often contributes to many of the internal inefficiencies and missed opportunities we see within today’s organizations.

There is often tremendous internal confusion regarding the role, span, and scope of a product manager.  Ambiguity in the responsibilities of this role leads to dissonance and tension as the key stakeholders in the value creation process – project managers, business analysts, and lead engineers – struggle to understand what to expect from product management. Given the profession’s historical fragmentation and lack of a solidified standard, where does one look? What are the boundaries of the role and how can we work together more effectively?

Perhaps the best way to start is by defining the role of a product manager and illustrating the product management life cycle. Product managers are responsible for creating and sustaining value throughout the entire life cycle of a product. The focus on creating and sustaining value is what makes product management unique.

GG1

This product management life cycle© model is the property of The Association of International Product Marketing and Management (AIPMM)©.

The product management life cycle is composed of both stages and phases that chart the course of a product from its conception, the Conceive phase, to its ultimate withdrawal in the Retire phase. The stages and phases are concurrent activities. This framework is universal; it applies equally well to products or services.

Now that we’ve defined the role of a product manager and illustrated the life cycle, we can drill down a bit further and examine why business analysts and product managers are perfect partners.

Effective product managers spend a significant amount of time in the market gathering requirements, monitoring trends, examining competitive activity, and evangelizing their product. Product managers are also expected to distill market information into actionable requirements and channel these requirements to the team developing the product.  A product manager’s job increases in complexity as the organization grows. Product managers get stretched thinner and thinner by the ever-increasing volume of internal and external demands.

When this happens, product managers naturally turn their efforts toward either market-facing or product development activities. Although product managers are skilled at both, they typically prefer one over the other and allocate their time accordingly. Many pick market-facing activities. This bias toward one or the other, and the demands that company growth place on a product manager, ultimately causes the organization to feel the need to add a business analyst, or someone with similar skills, to the team. The new team member is tasked with helping facilitate, communicate, analyze, and recommend business solutions as well as translating high-level requirements created by the product manager into implementable requirements. This need for translation necessitates a collaborative partnership between a product manager and business analyst.

The pairing of a strong business analyst with a market-facing product manager can result in a perfect partnership. The product manager assumes responsibility for guiding the product successfully through its life cycle and interfacing with the market. In concert with the product manager, the business analyst drives the effort to turn high-level market requirements into requirements that are implementable within the constraints and capabilities of the organization. Factors such as people, processes, and technology are all key considerations for success.

This division of labor leads to improved harmony with the principles on the core team of product managers, project managers, business analysts, and lead engineers. Most importantly, it places the right people in the right roles to create value for the organization, customers, and stakeholders.

The reality is that product managers are often faced with the nearly impossible challenge of spanning the market and the multitude of development activities. And like project managers who steer complex and interdependent initiatives, product managers who want to succeed must rely heavily on influence and shared organizational objectives while interfacing with customers and coordinating the activities of a myriad of internal stakeholders. Many product managers get stretched to the breaking point trying to be jacks of all trades and end up struggling against unrealistic expectations.

By pairing business analysts with product managers at key points throughout the life cycle of a product’s development, organizations can optimize bandwidth, expertise, and interest-related challenges that allow both roles to do what they do best – create value. 

Don't forget to leave your comments below.


Greg Geracie is the President of Actuation Consulting, a world-class provider of product management training courses and advisory services to some of the nation’s most well known organizations. Greg is also the author of the global best seller Take Charge Product Management© and the Editor-in-Chief of The Product Management and Marketing Body of Knowledge©.

David Heidt is a Strategic Advisor, Senior Project Manager, and Business Analyst with Enterprise Agility, a worldwide leader in strategy alignment, project portfolio management and business analysis. David is President of the Chicagoland Chapter of the International Institute of Business Analysis and a contributor to The Product Management and Marketing Body of Knowledge

Wednesday, 12 October 2011 09:50

Things Known and Unknown

Written by

On every project there are things we know and things we don’t know – Knowns and Unknowns.  Organizing your thoughts around those concepts can be a constructive approach to understanding a project as shown in the matrix below:

Knowns Unknowns
Knowns Known Knowns

Things in our plan
Known Unknowns

Things we know we don’t know
Unknowns Unknown Knowns

Assumptions
Unknowns Unknowns

??

The Known Knowns you handle via the plan, but what about those various flavors of Unknowns?  How do you normally account for those things in the project?  Often it’s with padding – estimates that include unidentified amounts of time and/or money just in case

Let’s review how padding works: You ask your tech lead, Renee, for an estimate: “Excuse me, I need an estimate for that activity you’ll be doing.”  Now Renee may be thinking to herself “That will take me about 40 hours.”  But Renee doesn’t tell you that.  She may very likely tell you “Um, that’ll take about 60 hours.”

Why would she do this and, more importantly, so what?  First, she’s doing it to cover her Unknowns. And that is absolutely understandable. Stuff happens – Unknowns!  So what’s the problem?

Padding undermines sound project management practice in three ways:

1.   It undermines trust. The notion that it’s a good idea to under promise and over deliver may work once or twice, but over time padding undermines the trust between the PM and the team and the rest of the stakeholders.  Honest questions should inspire honest answers.  That’s how you foster partnerships.

2.   Have closets, will fill.  If Renee says 60 hours, she may very well take 60 hours and that’s opportunity cost.  She isn’t able to be allocated to other efforts. 

3.   Padding undermines the opportunity to learn from our experience, which in many ways is the essence of why we seek to develop good project management habits.  What you want to be able to do at the end of a project is turn around and look at the journey you took to get there and be able to take something away for next time. 

If you pad estimates and quite possibly end up with nonsense for baselines, what do you learn from that?  Certainly not as much as you could have had you started with meaningful estimates to begin with. 

Let’s say Renee is thinking 40 hours, she tells us 60, and then she comes in at 50.  What do you think?  Renee’s a star!   But what really happened?  She was 25% over!  If you are measuring against meaningless numbers, you don’t get much of a chance to make the PM journey a learning experience. 

Importantly, the intention here is not to highlight Renee’s failures.  Rather, the purpose is to identify and understand the Unknowns that derailed the work and consider how to avert those things in the future or plan for them next time.

This is all well and good, but Renee still has her Unknowns to contend with, so what might you do to partner with her to address those? 

The better project management answer to Unknowns is contingency reserves, an amount of money in the budget or time in the schedule seen and approved by management.  It is documented.  It is measured and therefore managed.  You draw from it where and when you need to and then learn from that, as well. 

The purpose of the contingency reserve is not to 100% cover everyone’s Unknowns, but rather to reduce them to a level that is acceptable to the stakeholders.  So maybe it’s 10% of the project total if stakeholders aren’t too risk averse and you feel bullish about what you know and don’t know.  Or maybe it’s 40% on a project with highly risk adverse stakeholders and a big box of Unknown Unknowns.

Knowns we can plan for.  The Unknowns?  We have two choices for how to deal with those.  Under the table with padding which precludes any discussion, measurement, or management of what contributes to the Unknowns.  Or Contingency Reserve in which  case we talk about them, document them, measure and manage them.  Only one way really enables us to learn from them.

Don't forget to leave your comments below.


Andrea Brockmeier is the Client Solutions Director for Project Management at Watermark Learning.  Andrea is a PMP® as well as Certified ScrumMaster.  She has 20+ years of experience in project management practice and training. She writes and teaches courses in project management, including PMP® certification, as well as influencing skills. She has long been involved with the PMI® chapter in Minnesota where she was a member of the certification team for over eight years. She has a master’s degree in cultural anthropology and is particularly interested in the impact of social media and new technologies on organizations and projects.

Wednesday, 05 October 2011 10:36

Improving the Estimation Process

Written by

FEATUREOct5thEstimating is defined as an informed assessment of an uncertain event. For project managers, accurate estimates are the foundation for effective project planning and execution. There are many processes that have been developed to assist in the estimation process. Without proper estimating of project duration, cost, resources, risks and other parameters, it is impossible to implement proper alternatives and ultimately make timely and sound decisions.

There are five (5) main steps that an effective project management program engages to maximize success of projects which include: project planning; project baseline; reporting; change control; and project closure. Each of these steps rely upon accurate estimating and proper control to ensure project success. So what are some typical events that may impact the validity of your estimates?

  1. Poorly defined scope of work. This includes misinterpreted work elements, or the task granularity (detail) is not adequate for current phase of the project life cycle (PLC).
  2. Lack of knowledge for internal project cost (typically inability to determine accurate crew cost, resource productivity rates, indirects, etc).
  3. Inflated Optimism. The proverbial rose colored glasses way of guessing project problems or events.
  4. Inadequate risk management. Ignoring risks and uncertainty will skew the estimates and expectations become unrealistic.
  5. Time pressure or unrealistic targets. This is a miscalculation of the time a project task will take and failure to communicate what is reasonably achievable.
  6. Adoption of inappropriate estimation methodologies.
  7. Failure to utilize historical data or lack of accurate, meaningful historical data.  With so  
  8. many factors that could possible cause estimate inaccuracies, what can be done to make
  9. Your estimates the most accurate?
  10. Educate your project team and organization on estimating and require the appropriate project team members prepare the estimate associated with their scope aspect of the project.
  11. Reach out to a subject matter expert (SME) with experience for scenarios.
  12. Incorporate peer reviews and estimate validation processes into your PLC.
  13. Incorporate Risk Management and contingency assessment /re-assessment throughout the PLC
  14. Encourage estimate review and validation after each phase of the PLC.
  15. Accurate and timely documentation of change requests.
  16. Research historical data on the project effort, schedule, cost, risk and resources for lessons learned and make appropriate adjustments. Statistical baselines should be and revised periodically.
  17. Use mock ups, trial runs, field studies or other simulations as a guide.
  18. Adequately define work scope and accurately track time against each task.
  19. Develop and maintain Basis of Estimate Document.

Project Estimation should consider validation of project performance as measured against the plan for purposes of evaluating estimate accuracy and ensuring proper methodology is utilized. Metrics based on comparison of project estimates and corresponding actuals should also be utilized when making decisions regarding estimates of remaining or future work. A sound risk management program should also be implemented and should capture risk occurrence for current and future reference. Estimates should include applicable adjustments relative to risk management policies where necessary. Proper incorporation of Risk management into the estimating process will reduce project uncertainties and will enable better estimates. Finally, estimation methodologies should provide a basis for developing performance metrics used to determine project health and provide capability to make informed decisions on contingencies. It is important to develop a consistent process that can be utilized (on a graded approach if necessary) in all phases of the PLC.

In conclusion, there is an unrealistic pressure to complete projects faster, cheaper and more efficiently. By developing and implementing these control points into the estimating process, you increase your estimate accuracy and improve the probability of delivering projects accurately and timely.

Don't forget to leave your comments below.


Josh Medica, CEO and President of Integrated Consulting. Josh’s passion and commitment to project excellence has established him as a project management/project controls industry expert. He transferred that passion and knowledge into executive level master training classes on all topics related to project management and project controls.  Josh has facilitated risk workshops on projects ranging from id="mce_marker"0 MM to $2 BB .  His dynamic and thought provoking presentation style has positioned him as a leading trainer/educator. His speaking circuit also includes house training for large EPC companies, engineering companies, and major oil companies across the globe.