logo

ComputerImageAdobeStock45633013The purpose of this section of the PMINEO website is summarized as follows:

Focus: practical applications of project management within the Northeast Ohio region.

Examples of FEATURES articles (in no special order):

  • Project management case studies
  • Interviews with individuals important to or advancing the profession of PM within our region
  • Articles
    • Submitted by Members
    • Submitted by “Thought Leading” Speakers
    • Suggestions for reprints of “Thought Leading” content published by others
    • Announcements of new chapter services

Send your suggestions along with your contact information, suggestions for new content including links and attachments (as appropriate) to This email address is being protected from spambots. You need JavaScript enabled to view it.

Our 1st Feature Article this month is submitted by PMINEO Member Nik Kottha, Founding Consultant of Leanwrx Consulting. Learnwrx is based in sunny (sunny for today anyway!) Cleveland, Ohio. Anyone who has stood in line waiting for services (and who hasn’t) understands that there is still ample opportunity to improve performance in our emergent customer centric society. This article is certainly worth reading.

Share your thoughts with Nik through our Chapter LinkedIn group, PMI Northeast Ohio Chapter. 

I process mapped my last checkup, and it was a waste of time!

August 1, 2017 | by Nik Kottha |

One of the foundations of Lean Thinking is the determination of value added activities and non-value-added activities.

Checking-on-my-Check-UpWe often describe “value added activities” as things that a customer is willing to pay for. In other words: if you’re a manufacturer, your customer isn’t going to pay for your mistake when you had to remake a part 3 times, when you transported it 17 miles on your assembly lines before it got shipped or when they had to wait 5 days longer than expected because you didn’t have enough material to make the part. They paid for a certain part to be made a certain way and to be delivered on a certain date. The other activities above are wasteful and Lean is all about eliminating as many wasteful activities as possible.

What if we looked at this from a service perspective. The same concepts still hold true. Say you’re a customer looking to open a bank account for your daughter who’s going off to college in a week. You’re “paying” to have a certain account opened and usable within a reasonable time (usually 24 or less hours) and have a working debit card in 3 business days. If you’re the bank and you delivered a debit card two weeks later because you keyed the account number incorrectly and the processing folks never got the order for the card, it’s no surprise when your customer is angry.

Imagine that’s their first impression of a new banking relationship with you. Now imagine if they didn’t have access to their own money in time so they couldn’t pay their bills on time. These are small leaks that lead to a sinking ship of lost revenue and faith.

Let me give you a more personal example: I had a little checkup the other day on a knee that’s been giving me a bit of trouble. Thanks for the concern, but everything is fine! While waiting in numerous waiting in numerous waiting rooms, I took the opportunity to document my journey through this hospital’s system. Take a look and let me know what you think?

Timeline of My Hospital Visit

Hospital-Visit

The next time you’re out and about see if you can start identifying opportunities to cutout wasteful activities. And if you’re having a bit of trouble, give us a call and we can help!

Start asking yourself: What am I willing to pay for?

About Nik Kottha
Nik Kottha is the Founding Consultant of Leanwrx Consulting which is based in sunny Cleveland, Ohio. Nik founded Leanwrx with the premise that Process Improvement coaching and business growth shouldn't just be reserved for Fortune 100 Companies. Nik is passionate about solving problems and making organizations work better than they thought possible. His 10+ year background in Process Improvement and Quality Systems has helped a diverse portfolio of companies across the US achieve improved operations, eliminate wasteful activities, and increase profitability.

Agile-Best-PracticeIf you have been keeping up with the PMINEO Event’s schedule, no doubt you have noticed that we are in for a real treat!  PMINEO’s very own Board Member, Todd Jones, PMP, PMI-ACP is to be our Featured Speaker at the upcoming 9/21/17 chapter meeting.  Additional information about Todd can be found on his LinkedIn profile. Todd has also been a speaker at the PMI Global Convention and STPCon.  As a frequent featured speaker at other PMI Chapter events, Todd is fast emerging as a powerful thought leader in the project management industry.

His topic at the upcoming 9/21/17 Chapter Meeting is Putting Agile to the Test, A Case Study for Test Agility in a Large IT Project

RegisterNow

 

 

A downloadable copy of Todd’s recent article of the same name originally published at the PMI Global Congress – North America is found below.  We recommend it to you for your consideration as the article is definitely worth the read.

A summary of both the article and Todd’s presentation can be found in the abstract immediately below.

Abstract:

Agile best practices can be applied to a variety of situations. Most prevalent is IT projects, often for software development. But can you apply agile to a ‘portion’ of a software implementation project? This presentation will provide an overview of a successful example where agile techniques were applied to a multi-year, multi-million-dollar IT program – specifically to the testing phase. 

After examining this case study, you will have a greater appreciation for the testing complexity of a large-scale software implementation as well as techniques that can be applied quickly to your current project.

  • Scenario (what was the scope?)
  • Challenges (how did we get here?)
  • Approach (why was agile chosen? what was used to monitor progress?)
  • Benefits (what did we do right?)
  • Lessons learned (what could have been done differently?)

hydra

Editors Note: 

The following is a slightly adapted article written by Bill Murry of the Leading Edge Forum appearing in June 2017 edition of ComputerWeekly.com. While the article is geared to CIO’s and other IT professionals, the concept of antifragility can help project managers, regardless of their responsibility:

  1. By not only mitigating the risks of projects within the triple constraints of time, cost and scope.
  2. Focus on the greater good of their company by using the concept of antifragility as new risks emerge by the need to create and measure the desired business value within competing constraints.

We thought this article might make an interesting read while sitting around the pool of this comming 4th of July holiday!

By way of introduction to the antifragility concent, here is a quote from Nassim Taleb, the author of Antifragile: Things That Gain from Disorder:

"Consider that Mother Nature is not just “safe.” It is aggressive in destroying and replacing, in selecting and reshuffling. When it comes to random events, “robust” is certainly not good enough. In the long run, everything with the most minute vulnerability breaks, given the ruthlessness of time— yet our planet has been around for perhaps four billion years and, convincingly, robustness can’t just be it: you need perfect robustness for a crack not to end up crashing the system. Given the unattainability of perfect robustness, we need a mechanism by which the system regenerates itself continuously by using, rather than suffering from, random events, unpredictable shocks, stressors, and volatility.

By grasping the mechanisms of antifragility we can build a systematic and broad guide to nonpredictive decision making under uncertainty in business, politics, medicine, and life in general— anywhere the unknown preponderates, any situation in which there is randomness, unpredictability, opacity, or incomplete understanding of things.

It is far easier to figure out if something is fragile than to predict the occurrence of an event that may harm it. Fragility can be measured; risk is not measurable (outside of casinos or the minds of people who call themselves “risk experts”). This provides a solution to what I’ve called the Black Swan problem— the impossibility of calculating the risks of consequential rare events and predicting their occurrence. Sensitivity to harm from volatility is tractable, more so than forecasting the event that would cause the harm. So we propose to stand our current approaches to prediction, prognostication, and risk management on their heads."

The Hydra (pictured above) is considered by many advocated of antifragility to represent the prefect system.

 

Rethinking Risk Through the Lens of Antifragility

AAEAAQAAAAAAAAL6AAAAJDRkNWI3MzkyLTdiNjYtNGZiNi05ZDZiLTFjNTY3NmViNzQwYgBill Murry
Leading Edge Forum
June 2017

Antifragility is an exciting alternative that fuses value and risk, and CIOs and IT executives are well positioned to help.

We live in a networked world where everything – from nuclear power plants, factories, vehicles, fridges and hospital equipment to wearable and invasive devices – is increasingly connected, inspectable and controllable. Businesses are remarkably adaptive, but we are increasingly designing fragility into our systems and processes, particularly through efficiency and cost-cutting initiatives.

Are we ready for such unpredictable levels of risk? Businesses and government agencies have sleepwalked into the 21st century with organizations that are not fit for purpose. We need to evolve many aspects of our organizations, including how we think about, sense, manage, monitor and, more generally, address risk.

The traditional approach to risk management in business has significant flaws. First, we are, to some extent, managing risks that we have already seen or can imagine. This could be cruelly labelled as “managing risk through the rear-view mirror”, and does not address unexpected risks.

Achieving Solutions Through Robustness is No Longer Enough.  The current approach to risk management fools us into thinking we have risk under control, because we understand and have mitigation plans for expected risks. As author Nassim Nicholas Taleb points out:

Some things benefit from shocks; they thrive and grow when exposed to volatility, randomness, disorder, and stressors and love adventure, risk, and uncertainty. Yet, despite the ubiquity of the phenomenon, there is no word for the exact opposite of fragile. Let us call it "antifragile".

Antifragility is beyond resilience or robustness. The resilient resists shocks and stays the same; the antifragile gets better. This property is behind everything that has changed with time: evolution, culture, ideas, revolutions, political systems, technological innovation, cultural and economic success, corporate survival, good recipes (say, chicken soup or steak tartare with a drop of cognac), the rise of cities, cultures, legal systems, equatorial forests, bacterial resistance … even our own existence as a species on this planet. And antifragility determines the boundary between what is living and organic (or complex), say, the human body, and what is inert, say, a physical object like the stapler on your desk.

The antifragile loves randomness and uncertainty, which also means— crucially—a love of errors, a certain class of errors. Antifragility has a singular property of allowing us to deal with the unknown, to do things without understanding them— and do them well. Let me be more aggressive: we are largely better at doing than we are at thinking, thanks to antifragility. I’d rather be dumb and antifragile than extremely smart and fragile, any time.

It is easy to see things around us that like a measure of stressors and volatility: economic systems, your body, your nutrition (diabetes and many similar modern ailments seem to be associated with a lack of randomness in feeding and the absence of the stressor of occasional starvation), your psyche. There are even financial contracts that are antifragile: they are explicitly designed to benefit from market volatility.

Antifragility makes us understand fragility better. Just as we cannot improve health without reducing disease, or increase wealth without first decreasing losses, antifragility and fragility are degrees on a spectrum."

Consider that many historical events have been caused by so-called “black swans” – large, unexpected risks. The Fukushima nuclear incident was a negative black swan; Google’s creation of Gmail was, arguably, a positive black swan.

Another issue is that many aspects of risk management continue to require what was once considered a strength - human intervention, which is sometimes impractical in a hyperconnected, high-speed world. This becomes particularly important around adverse events when drilling for oil or operating nuclear or chemical plants.

Intelligent Risk

But the most troublesome aspect of risk management is its separation from value creation and growth. We often miss the considerable upside of taking intelligent risks because of crude approaches to risk assessment. If we are to survive and thrive in today’s 21st century world, we must change our way of thinking and dealing with risk. Antifragility is an exciting alternative that fuses value and risk, and CIOs and IT executives are well positioned to help.

If, instead of the “engineering” view of risk, we think of risk as an inherent, and not always bad, feature of all business, all processes and all value flows, then we approach what we might call a “financial” view of risk. In this view, companies choose activities that have attractive risk/return profiles or “yield curves”, and try to bend those yield curves to be even more attractive.

LEFrisk-chartThe goal of antifragility is to bend luck. An antifragile approach tries to bend the downside risk portion of the yield curve upwards, through what we might call “robustification”, and amplify the positive outcomes of the upside of the yield curve. In other words, we try to create an organization that stands to gain more in the good times than it stands to lose in the bad times. If a company can do that consistently, it will get stronger and more successful over time. Why would the world’s leading internet television network, Netflix, with more than 100 million members in over 190 countries, showing more than 125 million hours of TV shows and movies each day, deliberately break parts of its delivery infrastructure, regularly, and do so on a larger scale every year?

Let’s be clear – if that infrastructure fails, its programs don’t show. Subscribers cancel. Revenue growth slows. Executives lose jobs.

Netflix gets antifragility. It was antifragile before Nassim Taleb coined the term. Every time Netflix shocks its critical infrastructure (intelligently), the firm learns, restructures it and makes it perform better.

Toyota was antifragile before Netflix. Its massive 2009 car recall and the 2010 tsunami shocked its supply chains (and competitors’ supply chains). Yet Toyota’s 2013 profits were more than four times its 2010 earnings, and three times those of 2012. The firm built alternative suppliers and logistics into its supply chains and deployed crisis teams. The car maker examined its options, coped, learned, restructured and improved.

Similarly, the recent IT failure at a well-known airline could have been avoided by adopting antifragile practices, such as creating contingency and redundancy through cloud-based services and multi-cloud deployment, and adding architectural resilience by moving to “design for failure” approaches.

Such preparation creates options. Antifragility is a new term but an old concept. Whereas the term “options” could be considered old, it has many new applications. There will be a price – call it an option price – paid for avoiding catastrophes and having options in disasters. But it is a small price to pay compared with losses in the hundreds of millions from sustained global systems outages.

Jeff-SpahnLeadership used to be pretty simple. An authority dictated a vision down a hierarchical chain of command, and everyone else fell in line. But a new age requires a new approach.

Contemporary leadership models today tout the power of “collaboration” to meet this challenge, but with “collaboration” we’re rehashing an industrial age concept (“co-labor”). Leadership in the digital age needs to flow faster than the ferocious pace of information and change: leaders must learn how to lead and follow in the same moment.

In the past, the function of leadership and management was to enforce structure to create consistent results, and hold people accountable.

Today is different. As organizational cultures and structures evolve and priorities change, our approach to leadership must evolve towards fostering an innovative culture. The role of an Agile Leader is to encourage and empower cross-functional teams. This demands that team members are granted sufficient personal responsibility, accountability and authority to deliver the customers’ requirements.

According to our author, J. Jeffrey Spahn, Founder and CEO – Leading Leaders, Inc., we do this best through leadership that is not just collaborative, but mutual and simultaneous.

Research and experience shows that this new form of agile leadership, known as simultaneous leadership is particularly attractive to millennials. Attached is an article submitted to us by J. Jeffrey Spahn, Founder and CEO – Leading Leaders, Inc, which is attached to this article and is available for your download. Jeff was a speaker of the PMINEO Chapter Meeting in October, 2016. The attached article, MILLENNIALS WORKING IN HEALTHCARE: SOLVING THE LEADERSHIP DILEMMA, was originally published in the February 2, 2017 of Becker’s Hospital Review. Reprinted here with permission.

NK Shrivastava, PMP, RMP, ACP, CSP, SPC4 is the Keynote Speaker at PMINEO's 2017 Professional Development Day.  NK has been a recognized Agile PM thought leader for over 10 years.  He is the Founder and CEO of RefineM (https://refinem.com/), a consulting and coaching firm based St. Louis, MO.  NK will be recognized as one of the contributors and reviewers of the upcoming sixth edition of A Guide to the Project Management Body of Knowledge (PMBOK® Guide). He will be listed in the Final Exposure Draft Review section for his contributions during the production of the draft version of the guide. Being credited as a reviewer in this manner is both a testament to NK's influence in the field of project management and an acknowledgement to his commitment to further the overall body of knowledge as a professional consultant and trainer. 

We thought you might enjoy a preview of his PDD presentation addressing the same topic.

Shrivastava-NKNK is the lead instructor at RefineM and delivers most training courses conducted by RefineM. NK is CEO of RefineM and an experienced and certified Project Management Consultant, Risk Management Professional, and Agile Coach. He is a highly accomplished, strategic, and business savvy consultant with more than 25 years of experience in project management and 10 years of experience in Agile, and has led many successful agile transformations, coaching engagements, and training sessions. He is adept at initiating and maintaining large, complex projects on track while managing and mentoring teams of project managers and spearheading process improvements. 

 

Agile Practices for Waterfall Teams

Published on LinkedIN By: NK Shrivastava, PMP, RMP, ACP, CSP, SPC4

March 24, 2017

 

On a waterfall project, the bulk of the value is delivered at the end of the project. On an agile project, value is delivered incrementally through iterative cycles with the highest-value items prioritized, increasing customer satisfaction. Many organizations with traditional, or waterfall, teams struggle to transform to Agile. There could be many reasons such as; (a) they don’t have the support or resources/funding from the senior leadership, or (b) their code/functionality may be so intertwined that delivering in small chunks is not practically possible, or (c) the nature of their projects may require detailed upfront planning and/or one big bang delivery, or (d) the majority of the team members are nearing retirement and they don't want to change, or this, or that. 

The good news is that even if teams cannot fully transform to Agile, practicing Scrum, XP or KANBAN, they still have ample opportunities to improve their agility (satisfying customer through early and continuous delivery, inspecting and adapting on a regular basis, responding to the changes quickly, and more). There are several key Agile practices that waterfall teams can utilize and improve agility without going through the full Agile transformation and staying within the waterfall umbrella.  

AdobeStockTeamLet us talk about a very common practice that Waterfall teams perform. Usually they do "lessons learned" at the end of the project. What is the use of that? Not much. Usually, this remains a boring and merely a documentation exercise to satisfy a project process that someone developed. That is why several teams either don't do it or even if they do it, not many people attend it. How about using "Retrospective" practice of Agile instead? What if a retrospective is done, say every month, for a year long project? Don't change anything just practice "Retrospective" every month, learn from the past month and make changes to improve things in the next month. A Waterfall team can gain tremendous benefit by doing frequent retrospectives since they will be "inspecting and adapting" on a regular basis. It would be great if they can do it 2 times a month or even every week. The beauty is that this practice can easily be implemented with teams still staying within the boundaries of Waterfall. 

There are several other such practices that can help Waterfall teams improve their agility.

 

What these practices are and how waterfall teams can implement them? 

Many organizations with traditional, or waterfall, teams struggle to transform to Agile. The struggle could happen for many reasons: 

·         They don’t have the support or resources/funding from the senior leadership. 

·         Their code/functionality may be so intertwined that delivering in small chunks is not practically possible. 

·         The nature of their projects may require detailed upfront planning. 

·         There may be other reasons why they can’t transition to Agile. 

The good news is that even if teams cannot fully transform to Agile, they can still improve their agility. Read on to learn more about ten key practices that can be utilized by waterfall teams to improve their agility without going through the full Agile transformation and staying within the waterfall umbrella. 

1.    Maintaining a Backlog or Prioritized List of Requirements – Maintaining a backlog helps teams stay focused on the highest priority activities. Even though in waterfall projects the entire functionality is delivered in one big bang implementation (or in phases for larger projects), staying focused on what is most important is still valuable by enabling better resource utilization and giving stakeholders more control on what gets done first and what gets done later.

 

2.    Progressive Elaboration – Further refining requirement details as the project progresses helps to enable early and continuous delivery. Again, this practice is hampered in waterfall due to its structure, but many projects can benefit from a phased approach or the use of rolling wave planning.

 

3.    Smaller Iterations – Iterations between 2-4 weeks enable agile teams to benefit from more constant customer feedback, requirements elaboration, and continuous improvement through retrospectives. On a waterfall project, teams can seek more frequent reviews and touchpoints with the customer to achieve this ideal.

 

4.    Daily Standups – Daily standups are a 15-minute meeting to share progress, review the daily plan, and identify obstacles to success so barriers can be removed. Daily standups help teams become more self-organized, and even in command-and-control structures, teams can use daily standups to improve their work by identifying show stoppers sooner than later.

 

5.    Retrospectives – Retrospectives provide an opportunity for teams to Inspect and Adapt so they keep moving on the path of continuous improvements on a regular basis. In retrospectives, teams identify what is going well and what could be better, and determine action items for improvement. Waterfall teams can do retrospectives on regular intervals (say once a month) and make improvements as the project progresses rather than doing Lessons Learned exercise at the end of the project, which may not be very beneficial since the project is already over.

 

6.    Frequent Review/Demos – Frequent reviews / demos allow the team to better absorb customer feedback and respond to change. In addition, they increase customer satisfaction by giving customers greater involvement in the product. Waterfall teams can set frequent checkpoints with key stakeholders to get the same benefits very similarly to Iteration/Sprint end reviews.

 

7.    Use of Wireframes for UI Design – Wireframes is a white board exercise to outline the user interface (UI) structure in a simple manner so the team and the customer can brainstorm and develop a common understanding of UI without investing lot of time and resources creating UIs that users may not like. Waterfall teams can utilize wireframes for better UI design without changing their waterfall process.

 

8.    Visualize Work through Kanban Board(s) – Kanban Boards are visual representations of workflow using a physical or digital board with columns and swimlanes. Waterfall teams can utilize Kanban board to visualize their work, identify and resolve bottlenecks quickly to maintain a smooth workflow.

 

9.    Limit Work in Progress (WIP) – Teams operating at maximum capacity work slowly, like cars stuck in a traffic jam. By limiting WIP, agile and waterfall teams can develop a sustainable flow that keeps them at optimum productivity levels.

 

10.  Customer Involvement Throughout the Project – Engaging customers more frequently increases their satisfaction, lets the team stay ahead of changes, and results in more relevant project deliverables. All teams, whether agile or waterfall, should engage the customer regularly. 

Conclusion 

Adopting any of these agile practices may not transform a waterfall team to Agile but will greatly improve their agility and help them improve their project delivery outcomes.

 

Learn more about this topic and hear his engaging presentation by registering for the 2017 PDD to be held at the Holiday Inn - Independence on May 25, 2017.

Register-AdobeStock62896573

 

May 1, 2017

-years-AdobeStock62292003Jeffrey P. Bezos Founder and Chief Executive Officer Amazon.com, Inc. recently sent a letter to Amazon Shareholders.  The letter says a lot about why Amazon share price is trading at about $925 at a Price / Earnings ratio of approx. 174 (TTM), creating a current market cap of about $442 Billion.  This letter also provides us all with some lessons to learn about how and why our role as project managers is continuing to evolve so rapidly (see: https://pmineo.org/files/96/Chapter-Meetings/480/CLEPMI(2017)handout-distribution.pptx presentation by Dr. Harold Kerzner at the PMINEO 2017 Kerzner awards dinner). 

A complete copy of the letter can be downloaded in the PDF found at the end of the abstract, below.    

The retail sector is important to our analysis of the trends affecting the PM profession because as everyone knows retail most often feels the effects of changes in the economy.  For those of you wanting more insights in to how quickly the retail market is shifting, also see http://www.visualcapitalist.com/retail-apocalypse-everything-need-know/ 

 

Its Still Day 1 at Amazon

Abstract:

“Jeff, what does Day 2 look like?”

That’s a question I just got at our most recent all-hands meeting. I’ve been reminding people that it’s Day 1 for a couple of decades. I work in an Amazon building named Day 1, and when I moved buildings, I took the name with me. I spend time thinking about this topic.

“Day 2 is stasis. Followed by irrelevance. Followed by excruciating, painful decline. Followed by death. And that is why it is always Day 1.”

To be sure, this kind of decline would happen in extreme slow motion. An established company might harvest Day 2 for decades, but the final result would still come.

I’m interested in the question, how do you fend off Day 2? What are the techniques and tactics? How do you keep the vitality of Day 1, even inside a large organization?

Amazon-Logo-5117Such a question can’t have a simple answer. There will be many elements, multiple paths, and many traps. I don’t know the whole answer, but I may know bits of it. Here’s a starter pack of essentials for Day 1 defense: customer obsession, a skeptical view of proxies, the eager adoption of external trends, and high-velocity decision making.

There are many ways to center a business. You can be competitor focused, you can be product focused, you can be technology focused, you can be business model focused, and there are more. But in my view, obsessive customer focus is by far the most protective of Day 1 vitality.

  1. True Customer Obsession
  2. Resist Proxies
  3. Embrace External Trends and use High-Velocity Decision Making
  4. Fourth, recognize true misalignment issues early and escalate them immediately

So, have you settled only for decision quality, or are you mindful of decision velocity too? Are the world’s trends tailwinds for you? Are you falling prey to proxies, or do they serve you? And most important of all, are you delighting customers? We can have the scope and capabilities of a large company and the spirit and heart of a small one. But we have to choose it.

A huge thank you to each and every customer for allowing us to serve you, to our shareowners for your support, and to Amazonians everywhere for your hard work, your ingenuity, and your passion.

 

 

The following article, "The Ever Changing Dashboard" was originally posted by Dr. Harold Kerzner on Dashboard Spy http://dashboardspy.com/ .  Its well worth the read.  Also, if you are not familiar with Dashboard Spy.com, check it out.     

 

The Ever-Changing Dashboard 

by
Dr. Harold Kerzner
Sr. Executive Director for Project Management
International Institute for Learning (
www.iil.com) 

thDT65SW2NI have been a project manager for more than four decades. In all of my years of experience, my greatest curse has been the cost of paperwork on projects. Every piece of paper handed to a client can cost between $1200 to $2000 per page. To prepare a report, the steps we follow are: organizing the report, typing, proofing, editing, retyping, graphic design, approval, reproduction, distribution, storage, security classification if needed, and ultimately, disposal. As a rough guess, we estimate approximately 8-10 fully burdened hours per page, which includes everyone involved in the previous steps. For companies with high overhead rates, reports can consume a large portion of the project’s budget. 

Not all reports can be eliminated, but we can somewhat reduce the impact of this curse by striving for paperless project management, where appropriate. In the past, reports were needed to assist clients and stakeholders in making “informed” rather than seat-of-the-pants decisions on projects. Projects thrive on decisions, and decisions require meaningful and timely data. The bad news was that decision makers often had to read through volumes of irrelevant information to find the few pieces of critical data that they required. Fortunately, dashboards have come to our rescue in replacing reports. 

Dashboards-AdobeStock98957401The need for dashboards in project management is now quite evident. That’s why I became fascinated with Dashboard Spy. Unfortunately, the majority of the articles that I have read have a common thread: they focus on business intelligence data and information related to the long-term, ongoing business base of the company. The metrics in these dashboards may not change for decades, especially the financial metrics. These dashboards are more strategic than operational. 

To understand why these dashboards may not be directly applicable to project management, we need to look at how project management will work in the future. Consider the following steps, that are listed in the order in which I believe they will take place: 

  • The project manager and the client/stakeholders will meet and come up with an agreed-upon definition of success for that project. (Each project can have different success criteria.)
  • The project manager and the client/stakeholders will identify the competing constraints that will be tracked in order to monitor that the success criteria are being met. The constraints can be time, cost, quality, risk mitigation, safety, aesthetic value, etc. Each stakeholder may identify a different set of constraints, and metrics and Key Performance Indicators (KPIs) will be established to track each of the constraints.
  • The project manager will show the client and the stakeholders the core metrics that to be used on the project, namely cost, schedule, resource utilization, quality, scope and action items.
  • The project manager will show the client and the stakeholders their metrics/KPI library and ask the client and the stakeholders to select what other metrics and KPIs they wish to have displayed in the dashboards. The client and stakeholders may identify metrics that do not appear in the original library.
  • The project manager will try to get all of the stakeholders and the client to come to an agreement on what will be displayed on the dashboards. It is highly unlikely that an agreement will be reached. The project manager must then plan on the possibility of having different dashboards for each of the stakeholders and the client.
  • Because of the necessity for different dashboards, every project team may be assigned a dashboard designer knowledgeable in infographics.
  • As the project progresses, the client and the stakeholders may identify the need for changes to the metrics and KPIs. This may require additional effort from the dashboard designer.
  • Some of the metrics and KPIs may be applicable to only one of the life cycle phases of a project. An example would be the amount of money or percentage of direct labor dollars used for planning the project. As metrics and KPIs change, so might the construction and design of the dashboards.
  • When the project comes to an end, the project team is debriefed by the person(s) responsible for maintaining the metrics/KPI library. The metrics/KPI library is then updated. 

By now, you should recognize the differences in the dashboards needed for project managers. They include: 

A mixture of metrics and KPIs rather than merely KPIs: 

  • Throughout the life of the project, metrics may become KPIs and vice versa
  • The dashboards are ever-changing
  • There may be a wide variety of different dashboards on the same project
  • There must be flexibility built into the dashboard design so that changes can be made quickly
  • Every project team may require support from a dashboard designer 

data-mgmt-mckinseyHopefully, you are beginning to see the complexity of project management dashboards. Unfortunately, for some companies the situation becomes more challenging. For most BI and strategic dashboards, we know who the viewers will be. There may be only a dozen or so executives at the top floor of the building reviewing the dashboard information. But for companies that are managing project for external clients, the audience of client and stakeholder viewers can be several orders of magnitude greater than internal viewers. And each of these viewers may have different dashboard needs. It is impossible to develop standard dashboards that will satisfy everyone all of the time. 

When you manage projects for external clients, you always strive for repeat business. Follow-on work is based upon customer satisfaction and loyalty. Customer satisfaction can be directly dependent on the timely flow of meaningful information. At the end of each project, we generally debrief the client and stakeholders and ask them what we can do differently on the next project we manage for them. Most customers respond that they want the information displayed in the dashboard to be more closely aligned with their business model rather than your company’s business model. This may require new metrics. The price you must pay for this is the requirement for an ever-changing dashboard.

Project managers may have three information systems on their project: 

  • An information system for the project manager
  • An information system for the project manager’s parent company
  • An information system for the clients and stakeholders 

The first two bullets may be satisfied by standard dashboards that do not change often. The third bullet will most assuredly require ever-changing dashboards.

TKPI-AdobeStock119772378he last topic to be discussed is metric/KPI measurement. With strategic and BI dashboards, the majority of the data needed to support the information in the dashboards comes from the company’s information systems. Information on topics such as market share, new customers and profitability is relatively easy to measure and report. 

But what happens when clients and stakeholders want metrics that require complex measurement techniques? Before agreeing to provide a metric or KPI in a dashboard you must be sure that you understand how to perform the measurement and that you have people on the project team trained in metric measurement. As an example, clients today are asking for a metric that reports the ongoing value of a project as the work progresses. Without a good grasp on metric measurement, you cannot promise that this metric will be included in the dashboard. 

As can be seen, the dashboard environment in project management has some different requirements than the traditional BI dashboards and strategic dashboards. I enjoy reading the material in Dashboard Spy and encourage all of you who have ideas for the best way to design project management dashboards and ever-changing dashboards requiring flexibility in design to submit articles to Dashboard Spy. I look forward to reading them.

 

About Dr. Kerzner 

HAROLD KERZNER, (M.S., Ph.D., Engineering and M.B.A) is Senior Executive Director for Project Management for International Institute for Learning and Professor Emeritus of Systems Management at Baldwin-Wallace College. He has published more than 50 books (including later editions) on project management. His latest book is Project Management Metrics, KPIs and Dashboards, released in August 2011. Contact Dr. Kerzner at This email address is being protected from spambots. You need JavaScript enabled to view it.

 

rszlikeadobestock93635728Sharing project management knowledge and best practices with other PMINEO members is a great way to grow the project management profession and connect with your colleagues.  What better (and easier) way is there than by posting on PMINEO’s social media sites?

PMINEO has a LinkedIn Group and a Facebook Group where members can share ideas and post information for fellow project management practitioners.  It’s easy and fast.  Just read the how-to guide here: 

 

Any questions?  Feel free to contact either Jana Springer, PMINEO Director of Social Media, by e-mail here, by text to 330.840.0939 or email Jon Fedor, Assistant Director of Social Media .

(Please note that PMINEO’s social media groups are for sharing project management news and best practices.  Any posts not meeting PMINEO’s guidelines will be moved or deleted.)