Project problems can’t be solved with an operational focus

loves_distance__by_peggyopal-d41wf2f

loves distance by peggyopal

Straight from the Project Management Institute’s web site (and the PMBoK) is this definition of a Project

It’s a temporary group activity designed to produce a unique product, service or result.A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources.

And a project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal. So a project team often includes people who don’t usually work together – sometimes from different organizations and across multiple geographies. 

 Unfortunately, very often, projects are assessed by using metrics that are not about identifying unique & temproary activities.  Rather, persistent, on-going measures such as average weekly costs or hours worked or material dollars spent are used to determine if a project is running as it should.

Unfortunately, these sort of measurements are more attuned to understanding operations because they establish linear costs over time.  Project have peaks and valleys, spikes and low points, periods of tremendous activity and periods when they have very little at all.  Whether or not they should is a different question – there’s certainly plenty of room for levelling out the workload in projects and avoiding these ups and downs on the individual person, however, there are still times in the life of a project when you  may have multiple people working simultaneously on different sub-projects, and times when only 1 or 2 activities need to be going on.

As such, run rates for a project are erratic, as they should be.  Attempting to smooth costs on the entire project is dangerous.  It leads to people lingering on the project with little to do, just to keep the expenses constant.  Individuals or the departments they report to in a matrix need to keep spending flat.  Projects, however, are characterized by their temporary nature, and the ramping up and down of expenses can be considered an indication of efficency, not inefficiency.

There is, of course, much merit to the argument that bouncing people on and off a team leads to a loss of learning, mometum and flow – so it is better to have folks on the team continue to add cost, even if there is little for them to do.  I agree – right up until they begin producing work just for the sake of producing it.  If there is nothing of value for them to contribute, but disassembling the team creates a long-term problem, then look for learning opportunies within the project.  Have people sit in on working sessions outside of their functional area.  You might find people are adaptable to lots of different tasks, and this type of cross-training is invaluable when you need a pinch-hitter for an unexpected crisis.

Nonetheless, even when analyzing the cost reports for these activities, be very aware of who is doing what, such that you can distinguish between time spent adding genuine value through the transformation of work products and time spent in learning & watching.  Doing so will prevent assessing projects as the outcome on-going costs and, instead, allow you to determine the specific costs that create specific results which, in turn, allows for investigations into better methods for producing the same results.

 

 

Dad tells a story of inefficient communication, and truly wasteful meeting management

steelwork_by_roodpa-d4xunzm

steelwork by roodpa-d4xunzm

On a recent trip home for the Holidays, I was railing about such-and-wuch workplace goings on, when my father shared a story from his days managing projects in the construction industry.

His experience was in steel fabrication – the guys who take standard bpieces of milled steel beams, bars and plates and cut it into the pieces necessary to erect buildings and bridges.  As such, he worked closely with the erectors who took those custom-fabricated bits of steel and turned them into the skeletons around which the rest of the structure was put together.

Often times, he told me, he would have to report to the job site for a project status meeting.  The general contractor, or whatever entity was in charge, would require all the leads of the various teams to report out and hear what was happening and where the project was, and establish any hand-ins and hand-outs that had occurred, or needed to occur.  None of which sounds too terrible, of course.

That is, until Dad also let me know that, as the “steel guy,” most of his work was done fairly early in the life cycle.  The steel was cut, fabricated, delivered, erected, corrected, charged back, and his end of the project entirely signed off.  Nonetheless, he was bound to attend these hours-long meetings at times, just to hear how the electrical inspection and finished carpentry was progressing.  His activity on the overall project was long since done and over with, nonetheless, in the name of communication, he was required to attend.  The fact that the meeting would never include any information he needed to hear was entirely lost on the meeting’s organizer.

So it goes with most meetings.  Well-intentioned people will often, in the name of completeness or the feel-good sensation of having shared information with the entire group, call large all-hands meetings and blurt out every bit of info under the sun, just so everyone is “on the same page” and can understand the “project environemtn” and “paths to success.”  Unfortunately, what gets lost is that the project is made up of many, many mini-projects and, just as the PM does not want to waste time and cost by speding effort on anything not relevant to his or her project, so it is with the leaders of all the mini-projects, too.

Communciation for the sake of driving a necessary decsion, from the necessary decision makers, is valuable.  Communication for the sake of team building and understanding is valuable, too.  Communication for the sake of adhering to formal or informal protocols or because “this is what we’ve always done,” or because of a single-sided belief that people want to hear what you have to say is misguided.  People like to know what’s going on if it helps them to get a job done.  Otherwise, all that communication is just a hindrance to some actual accomplishment.

Why your PMP prep doesn’t feel like reality (and why it shouldn’t)

A Break in Reality

A Break in Reality by xetobyte

I am in the midst of a PMP prep examination these days, diving deeper into the project PMI’s methodology for project management than I ever have before.  Despite more than a decade of working on nothing but project & program teams, I’ve never gone after PMI certification.

True to my affinity for Lean thinking, I don’t put much stock in these type of certifications.  The class is bearing out that the intent is simply to pass the test, not build better project managers.  Everything is about the test, the test, the test – and there is very little about the development of the principles taught and how they came about.  Just. Pass. The. Test.  The test is also intentionally deceptive – minor turns of a phrase mean different things in “PMI Land” as the instructors like to call it.  A big part of passing the exam is tuning your eye to catch these clever little interpretations and usages – a skill which is useful for only 1 project: passing the test.

It is easy to understand why so many fellow students get frustrated and jokingly state that the exam does not reflect reality.  Unfortunately, what seems to get lost, is that it’s not supposed to.

What?

As I study the guidebooks for this class that are introducing us all to the PMI concepts, I am harking back to my Lean training and the years I’ve spent contemplating Operational Excellence through my writings on this blog.  In my mind are the oft-repeated Lean-thinking mantras: “Theory guides practice” and “There can be no improvement without a standard.”  Thank you, Dr. Deming and Mr. Shingo (and, please, OpEx gurus out there – correct me if I am quoting them wrong.)

I feel lucky to have the benefit of my time spent trying to understand the Lean paradigm because it is offering so much insight into what the PMI framework is trying to do.  It is establishing a standard.  It is offering a methodology for managing projects against which all other management styles, and outcomes, can be measured.  In a way, it depicts the ideal – if all projects, everywhere, operated in the way the PMI describes, then all projects would deliver on time, within budget, and with inputs from all stakeholders at every level of the organization – including customers.

Is that reality?  No.  Of course not.  If the standard was reality, there’d be no need to set up a test for it.  A standard is not meant to depict reality.  What it does do, however, is give us an ideal scenario against which to judge and measure the current state.  How far from this standard are we?  Did we make an intelligent deviation, based on detailed analyses of how our environment differs from that depicted in the standard, or did we simply throw up our hands and say, “But this is the way we’ve always done it?” (Or words to that effect, such as “I’ve never seen that” or “That just won’t work here.”)

When theory doesn’t match reality, there are 2 options:  Change the theory to match reality, or change reality to match the theory.  Those who argue the PMI framework just isn’t reality will be the ones trying to change theory in order to better align with their expectations – nearly all of which demonstrate a daunting tolerance for inefficiency & waste.  On the other hand, if you accept that the “theory” is really just a depiction of the ideal – you instantaneously give yourself something to work towards.  It is the “true north” of the program & project management world – to have a perfectly managed, documented, planned, monitored, tracked and executed set of activities that are completely understood and performed by all stakeholders.

My advice for those who are poo-pooing the PMI framework as nothing more than an academic exercise designed to pass a test (which, to some extent, it is), is to think of the methods provided within the framework a bit differently.  The tools and techniques they teach are not  a set of instructions on how to effectively manage projects.  Think of them, instead, as a depiction of a perfect universe – and use that depiction to begin thinking about the gaps between your current reality and the PMI’s idealized scenarios.

 

Project Management & Measurement gamed

Measurement

Measurement_ by spacesuitcatalyst on deviantart.com

In a recent article on his blog, Dan Markovitz offered this statement:

“One problem with stretch goals, I believe, is that they focus on outcome metrics, and can therefore be gamed.”

That got me thinking about how we analyze and measure progress on business projects.  All too often, I have seen project leads engage in gaming metrics as if their ability to adjust the numbers was the real purpose of their jobs.  As I indicated in my comments on Dan’s article, “How do we make these numbers look better” is an operational question, not a spreadsheet exercise.

Yet, project management tends to be all about outcome metrics.  Tracking costs vs. plan, Earned Value, Cost and Schedule Performance Indices, consumed slack – all are about what happened.  Granted, there’s an effort inherent to those practices that says the future can be predicted by understanding the past, however, that approach also seems to indicate that errors are acceptable.  Especially if we read a bunch of charts and graphs and variance analyses to tell us that we had a problem some number of days, or weeks, ago.

Somehow, that doesn’t seem good enough.

I’ve seen far too many managers who are completely distant from the day-to-day operations of the projects and processes that ought to be occurring right under their noses but, unfortunately, have become dependent upon analyst-manipulated reports to convey information.  This reality only seems to point out the importance of applying concepts such as leader standard work  to project management and controls.  Simply put – leaders need to have an understanding of not just the outcomes and results of their team’s efforts, but to be inherently familiar with the mechanisms and processes by which that work gets done.

When those processes are not measured, analyzed and understood – all that’s left is a pile of reports measuring the outcomes.  When those metrics don’t show things as expected, then there’s a loose interpretation of the inputs that goes on – in order to justify the manipulation of numbers before they get passed on to the next level of review.  “The data doesn’t reflect reality” or “we need to make an adjustment to the numbers” is heard all too often.  If the data is so easily, and subjectively, corrected then its method of collection can also be easily corrected, too so that good information is passed along, not manually tweaked information that results in nothing more than watermelon reporting (the phenomenon by which red projects get greener as the reporting moves higher up).

The best way out of this?  Understanding the way in which the metrics are compiled is one.  The better solution, however, is to be involved.  Know who is working on the team, and why, and how they work, and what they are working on.  Engage in the human elements and be aware of not only what is going on, but what should be going on.  This places a premium on good planning and strong servant leadership.

The worst project & program managers I’ve ever worked with very often never looked at the reports that were provided to them.  They simply didn’t understand the information and/or believed that force of personality was sufficient to effect positive outcomes.  Some of the best I’ve worked with didn’t read the reports, either – because there was nothing in all that data that they did not know already.

The state of the blog (and the blogger). Or, how did I get here & what am I going to do now?!

ON THE PATH TO THE TRUTH

On the path to truth by Chryssalis on deviantart.com

March is the 2 year anniversary of this blog.  It has had a lot of ups and downs, gone through some periods where I did very few updates and considered killing the site altogether, but I am proud to say that I’m still here.  To be honest, I couldn’t image NOT writing this blog.  It’s one of the most gratifying things I’ve undertaken and continues to be a terrific learning experience as well.

I started the blog about 1 year after my introduction to Lean via a GBMP training class, almost 1/2 finished with an MBA program and, of course, looking to the future and using the blog as a way to grow my network.  Two years later, I’ve finished the MBA and have had opportunities to interact with people from many different professions, in a way that is down-to-Earth and honest.

Looking back, a lot of those initial posts aren’t great, but they also aren’t nearly as bad as I thought they were, either.  I can point to a few distinct phases in the writings I did over the past couple years that help me remember what things were on my mind and what interested me, personally, professionally, or intellectually.  True to the blog’s title, I gave myself permission to meander a bit from subject to subject, and write down my thoughts as I experienced things from day to day.

I’ve discussed Lean a lot on this blog.  Lean, you could say, offered me some much-needed evidence that I wasn’t completely out of my mind.  What my Lean training showed me was that the things I experienced at work that frustrated me so greatly had been noticed by a great many other people who were passionately working to change them.  I attended the 2010 Northeast Shingo Prize conference and heard a talk given by Lesa Nichols on the concepts of mura and muri and the “people side” of lean, which put into my mind that the workplace itself can be, and should be, much more focused on the cares and concerns of the people doing the work.  As a result, I have discussed mura and muri on the blog several times since.

I’ve also written a great deal about project management and the dynamics of project teams, which I’ve built up quite a few observations on over the past 12 years or so working in Program Planning & Control.  More recently, I’ve been blogging about workplace change, management improvement, Lean and ROWE, in particular.  It’s fairly well understood that the typical workplace is broken.  The expectations placed on people to live with this broken system are tremendous and unfair.  The vast majority of workers are frustrated and hollow – which is no way to live a life.  ROWE offers some solutions, but while the concept is enormous, its practical applications across all possible environments is still in its infancy.

Once in a while I talk about family life, too, and I attempt to integrate some of what I’ve learned about project management and Lean into those discussions, too.  I find there’s a tremendous amount of insight into just how all these theoretical concepts and tools work when you apply them to something that really matters – like your own family and your household.  There’s nothing more salient to me than finding a way to apply what I believe should be the way to do things, intellectually, to the day-to-day concerns that we all have to deal with, emotionally.  That’s the true intersection of life and work, in my humble opinion.

There’s more to the Lean and ROWE discussion, however, than just those two concepts.  What I see for the blog as I look into the future, is more discussion of Operational Excellence, which includes but is not necessarily limited to Lean, and how those concepts can be applied to the larger concepts of virtual, flexible work.  Clearly the world is trending in that direction, with the rise of technology that is enabling greater mobility.  The tools and methods that make Lean work so well, however, will need to adapt to this changing workplace.

This changing workplace brings a number of challenges.  Management styles will need to adapt, as will working styles.  Security concerns are massive, too.  Nonetheless, it’s a space not explored in any great depth that I have seen, which appear to make it ripe for the picking.