With Major League Baseball Spring Training just around the corner, let’s look at what one of the most interesting books I’ve read in a while that can potentially help manage your business, whatever that business may be.
One of the most enjoyable books I’ve read lately is Moneyball: The Art of Winning an Unfair Game by Michael Lewis. Lewis describes how Major League Baseball’s Oakland Athletics, with a “measly” $41 million roster payroll in 2002, figured out how to compete with the “big boys” like the New York Yankees with a $125 million payroll.
Moneyball puts forth the notion that the collective wisdom of baseball experts (players, managers, coaches, scouts, and the front office) over the past century is mostly subjective, and even worse, often unsound. For almost as long as baseball has been around, scouts venture out and evaluate players all over the country, not paying particular attention to statistics, but rather base decisions on the five tools: speed, quickness, arm strength, hitting ability and mental toughness. Add in the nebulous “he looks like a baseball player” in the mix and the odds of finding the next Joltin’ Joe or Hammerin’ Hank are slim to none. This is not to say that scouts don’t look at statistics at all, but the ones they do look at such as stolen bases, runs batted in (RBIs), and batting average were each a bit flawed in their own way.
The Oakland Athletics’ front office took advantage of more empirical gauges of player performance to field a team that could compete successfully against richer competitors in Major League Baseball. The A’s focused their future player evaluation on Sabremetrics, an analytical, evidence-based approach, in an effort to assemble a competitive baseball team, despite Oakland's obvious disadvantage in revenue. As a side note, Sabremetrics is a term derived from the acronym SABR, which stands for the Society for American Baseball Research. The A’s management created an analytical literacy that included both “what to measure” and “how to measure it”.
For hitters, they focused on a wider set of metrics instead of the traditional metrics such as batting average and RBIs. They evaluated offensive effectiveness with an additional two metrics: (1) on-base percentage (OBP) and (2) slugging percentage. Combining these two stats, they formed a new statistic called on-base plus slugging (OPS). In short, they went from a viewpoint of “Can he hit?” to “Can he get on base?” The underlying theory is that the more runners that get on base will yield more runs scored. Of course they also looked at pitching and defensive statistics, but I don’t have time to go into that here.
The A’s believed this causal relationship should improve the chances of winning. And it did. The A’s won the American League West Division title in 2002. Unfortunately they lost the Division Series in the 1st round of the playoffs to the Anaheim Angels.
So how does all this relate to your business? Regardless of what business you are in, there are some traditional metrics that have been used seemingly forever to define “success”. For example, “on time” and “on budget” are the two mantras typically used to define success for project managers. But deep down there may be more metrics that can define success that goes beyond what’s included in the PMBOK.
The challenge for you is to take a critical look at your industry and company to establish an analytical literacy that gives your organization a competitive edge. Good luck on your adventure to find out “what to measure” and “how to measure it”.
Have you ever asked a group of project managers or team members the intentionally vague question, "How do you handle risk on your project?" You might hear:
» We have a risk register.
» We have a consultant who handles that for us.
» We did that at the beginning of the project two years ago.
» We handle risk very well on our project. I think we do ours with Monte Carlo.
» We have contingency to take care of our risk.
» We have a risk management process that enables us to identify, analyze, and manage our opportunities and threats from project conception through closeout.
The varied responses often show a broad understanding of what risk is and how it should be "handled." This series of posts will explore some of the key concepts and misconceptions relating to project risk.
Three terms that often get mentioned in these conversations are risk register, risk analysis, and risk management. The terms are not synonyms!
What is a risk register? The risk register (or risk log) on some smaller projects may be a simple listing of identified risks (opportunities or threats) and the appropriate responses. However, the risk register can be a focal point repository for the management team that includes other data such as unique ID, risk title, risk description, probability of occurrence, impact ranking, risk score, cost estimate, schedule estimate, pre-mitigated, risk owner information, risk type/category, status, triggers, RBS (risk breakdown structure) assignment, contingency, etc. One software program I use has more than 120 various data points that can be tagged for each item in the risk register!
Suggested components for a basic risk register:
» Unique ID or Number
» Risk Title
» Detailed Description or Definition
» Risk Owner/Manager
» Risk Category
» Probability of Occurrence
» Impact of Occurrence (schedule, financial, and/or scope)
» Mitigation Strategy or Steps
The following may also prove helpful:
» Review Date (In what time period will this risk be important for the team to review? This can be a specific date, time period (i.e., second quarter), project phase, etc.)
» Trigger(s) (Is there a planned or potential project event that will change the risk time frame, probability of occurrence, impact, mitigation strategy, etc.?)
» Impact Post-Mitigation (schedule, financial, and/or scope)
» Ranking (based on the probability and impact matrix)
» WBS and/or Schedule Activity ID Affected by the Risk
» Additional Notes
It is important to note that the development of a comprehensive risk register is not the same as risk analysis or risk management. The register is part of the fuel that feeds the analysis but it is not analysis. It will be an essential tool in the risk management strategy but it is only one tool in the toolbox. In future posts, we will look further into risk analysis and risk management.
Is using project management methodologies enough to ensure a successful business? The simple answer is no. Successfully executing individual projects does not guarantee overall business success unless they are the right projects to meet the business objectives. Project selection is outside the scope of the project management purview. Controlling this selection and prioritization process is the precise purpose of Project and Portfolio Management (PPM). PPM focuses on generating strategic alignment to ensure that we collectively as a business are doing the right things to achieve success.
Complicating this effort is the element of time. As a portfolio of projects is established, each project is not started at a single point in time nor do they typically progress at the same rate. This places each project at unique phases throughout the portfolio’s lifecycle. What this means for the selection process is that it does not occur once. The process must be robust enough to manage the evolution of the portfolio; continuously re-synchronizing the individual projects with the outcomes the portfolio intends to achieve.
In future discussion we will elaborate on three key PPM systems essential to managing business alignment and introduce their methods, disclose how they can be individually leveraged and recommend ways to integrate them continuously to enable business success. Without systems such as these, organizations can often become unbalanced in their tactical approaches to success, under/over-utilized in their resource assignments and so focused on short term results that they lose sight of their strategic long term vision. Implementing these systems in your business will enable your projects to not only deliver their promised results, but also ensure those results are resources and time well spent in the pursuit of success.
Stay tuned to read how Portfolio Prioritization, Risk Management and Performance Monitoring can provide a framework upon which your organization can begin to mature. With these as the foundation for your PPM System you will see the tangible benefits this methodology can provide and accelerate the commitment to enterprise management concepts in a positive atmosphere. These systems are common in their ability to inform decision makers and evolve as business cycles shift while maintaining focus on the long term vision of leadership.
Project Reviews Round 2 – Using Project Reviews for the Smaller Projects: Project Reviews are generally used on a monthly or more frequent basis on larger, high profile projects to facilitate communication and resolve issues, but often smaller projects are left alone. However, Project reviews can be a great tool for keeping smaller, less visible projects on target and out of trouble. Project management, corporate management, clients, and other stakeholders should meet on a regular basis, such as monthly, to review the project's cost, schedule, and technical status. Reviews for these projects don't have to be long or detailed, but regular meetings will facilitate communication and improve accountability from the project team. How often do you get your project team together to review status reports?
I am currently working on a demolition project that has good technical scope with a schedule of values. I have a few support activities that are categorized as level of effort (LOE) activities. LOE activities are typically support activities with no defined deliverable, which support other work. On this particular project, we have an LOE activity that is related to an activity that uses physical percent complete. In some instances, the physical percent complete of the discrete work activity and the LOE percent complete are not aligned. For best management of the project, does this give an accurate earned value? I would love to hear your thoughts and experiences with this.
A traditional (waterfall) software development approach provides a highly structured and linear design process that relies heavily on detailed up-front planning where each phase must be completed before moving sequentially on to the next one.
One main disadvantage to this approach is there is no realization of any business value until the end of the project, in addition; you will rarely (if ever) return to a phase once it is complete. Therefore, there is only one opportunity to get it right and there is usually one large product integration at the end of a project. This type of big bang project delivery approach can increase risks and can lead to a product that does not meet evolving system requirements.
In contrast, agile utilizes an iterative and incremental framework for delivery where each iteration delivers a fully functioning increment of software. Basically, iterative development allows time for improving on what has already been developed, while incremental development breaks up the work into smaller chunks as they are integrated and adjusted as needed.
Rather than just continuing on with developing the next cycle of a product without feedback, an agile team will elicit customer response to software as it is delivered. This provides a powerful inspection and adaption loop for future product iterations and increments while reducing project risks and increasing customer satisfaction.
Value is defined by the ratio of Function to Cost (Value=Function÷Cost). People make choices every day based on perceived value. We think about value all the time, whether it is a major purchase such as a car or house, our next vacation destination or even choices as mundane as picking a restaurant or movie. Everyone wants to get the most "bang for their buck". The same holds true in business.
In the business realm, managers make value-based choices for everything from office supplies to construction projects. Different purchasing decisions have different definitions of value. For office supplies, value might be driven by the vendor's ability to provide same day or next day delivery, their selection of products, and of course, cost.
In contrast, construction projects tend to have a much more complex and multi-faceted definition of value. Not to mention the potential for significant financial consequences if the building, road, bridge or utility system doesn't perform as intended.
With the ultimate goal of obtaining maximum value, all phases of a construction project have critical decision points where outcomes can be contrary to that goal. Without a repeatable method to evaluate design and construction options, unnecessary risk may be incurred during the project lifecycle. To help minimize the risk associated with the decision making process, firms are implementing Value Engineering.
Value Engineering (VE) is the commonly used name for the systematic and structured approach used to improve projects, products and processes. Traditional VE efforts have historically been focused at either the project kickoff phase or the construction bid process phase of construction projects. These traditional approaches, while value-added, have some intrinsic failure modes that can be addressed by utilizing VE techniques during all phases of the project.
Construction Project Solutions, LLC (CPS), in partnership with Greene and Associates, has developed the Ci2 Integrated Value Engineering approach for facility design and construction. The Ci2 process integrates VE concepts across the entire project lifespan, from initial design through project close-out. The Ci2 process supports decision making that aligns with both the project goals and overall business goals for everyone involved with the project. This ongoing evaluation process promotes the generation of value creating ideas at all phases of the project and ensures the ideas are evaluated and carried through the project.
To learn more about the Ci2 Integrated Value Engineering approach for facility design and construction, please contact Construction Project Solutions at 865-474-9789.
Using the store financial option in Primavera P6 can give you a great tool for managing and reporting your earned value information. This feature allows you to store your actual, planned and earned value information by your financial periods. This information is then available for reporting, and tracking. However, occasionally, your data can get "lost". You may notice when you sum the individual period data, including your 'this period' data, it doesn't equal your cumulative data. The data is stored in the database but not showing in any period. To fix this, you will need to go to the projects view and click on the calculations tab. Then uncheck the link actual and this period costs option (your project will need to be open), and recheck it. This will recalculate by subtracting all stored financial periods from the cumulative values for planned, earned and actual. This will relink the values and put any differences in the 'this period' fields.
Why do you need project reviews if you’re not having any issues on your project? I’ve seen organizations where this is viewed as a waste of time and resources in some organizations. However, the value of a regular project management review is tremendous in my opinion. Having a monthly review forces regular updates of project information, regular analysis of project status and is invaluable in communication of project issues, current and potential. A project review should have a standardized format for reports and a set time each month. Project financial, scope and technical status should be reviewed and any issues identified, documented, and communicated to upper management or clients as appropriate. For most projects, earned value analysis is appropriate on some scale and project managers should understand and explain variances which occur. The review should allow for honest dialogue between the project team and management and/or clients on project issues. Open discussion can eliminate potential issues, allow for early resolution of conflicts, identify new risks both positive and negative, and keep all stakeholders on the same page.
How Can There Be This Many Percent Complete Options!
A friend who is moderately new to Primavera P6 recently wanted to add percent complete to her activity layout. She was somewhat overwhelmed with the number of choices available. Here is a simplified look at what percent complete can mean in the Primavera world.
Activity Percent Complete - There are three options for activity percent complete. Each of these percent completes is calculated and available for each activity, the selection in the General tab indicates which one is tied to activity percent complete.
» Duration % Complete will calculate the activity percent complete as (Original Duration-Remaining Duration)/Original Duration*100. This can work for level of effort type work.
» Physical % Complete requires the user to update the percent complete manually. This allows you to reflect the technical percent complete of a task regardless of the duration. This percent complete should be based on an objective measure of the task's progress. Steps can be used to track individual components of an activity to help you calculate this.
» Units % Complete will calculate the activity percent complete by taking the actual units ((labor and non-labor)/(actual units (labor and non-labor) + the remaining units (labor and non-labor))*100. This will work for activities where the expenditure of resources against the forecast accurately reflects the progress of the task.
There are also other percent completes you can show in layouts and reports. Some of the more commonly used of these are:
» Performance % Complete is used to calculate earned value. This is calculated based on settings in the Earned Value tab of the WBS. It can be based on the activity percent complete, 0/100 or 50/50, milestones or a custom percent complete.
» Schedule % Complete shows how much of the activity should be completed based on the baseline's duration.
» Cost % Complete is calculated as (Actual Total Cost/At Complete Total Cost)*100.
» Cost % of Planned is calculated as the (Actual Total Cost/BL Total Cost)*100
» Steps % Complete shows the WBS percent complete based on the WBS Milestones that are assigned.
So, make sure when you are reporting percent complete in Primavera, you understand which value you are reporting and what it represents, and it can save you unnecessary problems.