« June 2007 | Main | August 2007 »

July 31, 2007

Risk Management (Part 1): Metro Plans

Risk_diceI recently completed a risk assessment for a client on a major metropolitan master plan.  We followed a failure modes effects analysis format that I modified to fit for real estate...Once I clean it up, I'll post the template on this blog

We looked at each major workstream for potential problems so that we could properly advise senior executives of their exposure:

  • Sale/leaseback of an existing anchor property
  • Selection and Programming of the destination buildings
  • Design and Construction of the destination buildings
  • Move/Migration of employees

Good project managers have an inherent understanding of their risks but the value in using a more systematic framework is that the entire program team could achieve alignment on relative severity of various apples/oranges risks.  Prior to this time, transaction risk and project risk weren't really integrated and compared. 

This approach provided some needed transparency to decisionmakers and program managers alike.

July 24, 2007

Is Your CRE Group Customer-Centric?

There are a variety of ways to approach the planning, running, and organizing of a corporate real estate organization.  The group might not even be a "CRE" group -- I worked with an organization which for some time was a cutting edge (innovative) CRE team.  Under new management, they were re-tooled as a more operations-focused "Facilities Department."  But, I digress...Customer

Plenty of CRE groups are organized along geographic lines, functional lines, or a combination.  The pressures on corporations to outsource non-core functions and to get "more" from their workplace generally lead to the conclusion that these organizing principles are insufficient.  Here are a few questions designed to suss out whether a CRE team is customer-centric:

  1. What is the position of the group leader in relation to the operations of the business?  Whether through a reporting structure or through executive management group matrices, the head of CRE should sit at the table with operations.  A reporting structure is through Treasury up to the CFO is less conducive to partnering with the business.
  2. What staff report to the head of CRE?  If direct reports are aligned to geographic duties or to functional duties, with a business partner buried somewhere, your group is not likely to be customer-centric.
  3. Do you have staff assigned to build advisory relationships with the business?  If so, what level are they?  They have to be fairly senior to pass this test.
  4. Do you have a group dashboard that includes business-relevant metrics (e.g., speed to market, business continuity)?  Or are you reporting square footage and density metrics and wondering why your businesses don't care?
  5. Have you mapped your planning and delivery processes to those business-relevant metrics?  In other words, do all your staff, by virtue of knowing their role in your core processes, have line of sight into how they are contributing to the real needs of the business?
  6. What does the CRE leadership say when asked "Who are our customers?"  (I'll leave the answer to this up to your imagination.)

I could go on, I suppose.  But in my experience, these are the critical few indicators.

July 17, 2007

My 84%-Defective Measurement System

Needless to say, a measurement system this bad (835,000 DPMO) is not worth much to a client.

When we started the measurement system analysis project on one client's transactions dashboard, everyone already knew that only a couple transactions managers used the system consistently.  It was suggested that we wait until usage went up before we bothered auditing the system's quality.

(This happens a lot, actually -- people want the chance to improve before being measured.  But this system had been in place for over a year, with periodic reminders to keep it up to date.  It would stay up to date for a bit and then the weeds would grow back.  So we decided to put a metric on it.) 

Now we know which data fields are missing, which are inaccurate, and which are out of date beyond the client's tolerance level.

The biggest debate was over setting a spec limit for how up to date the data needed to be...we settled on "no more than 2 weeks out of date" because management hold official reviews of the reports once a month.

We know who keeps their information up to date.

And we know what kinds of information is most likely to be inaccurate.

Where we saw differences in participation, we asked why.  We know some people opt out because their access to the system is too slow.

This is helping us in our training and change management effort.  And instead of waiting until improvement happened before we measure, we can watch the improvements come in and give credit to the people doing that work.  We can publish measurable expectations for how performance should improve over time and tie that directly to performance reviews for individuals to be accountable for their own data and for managers to be accountable for the data for their department.

If we don't flip from 84% defective to at least 84% throughput in short order, shoot me!

July 09, 2007

Oops! We (almost) fired the project managers!

I recently worked with a client with a retail business unit.  This client wanted new stores opened, on average, in 180 days from order to construction.  I didn't think the metric was adequate but at least I could give them kudos for measuring an important part of their business and for diligently collecting performance data. 

Data showed that some project managers were improving their performance, i.e., achieving project completions that were nearing the 180 day average.  But there were a few PMs who weren't making very good progress.  Management kept whipping the horses but it didn't do much good.  Everyone was frustrated.

They thought project managers were the driving difference.  They turned out to be a "big X".  Deeper (but not much deeper) analysis showed that it was a function of geography -- again, only a "big X." 

Histogram_of_submit_to_end_construcTurns out that variation in municipal requirements (another "big X") was causing permitting times to be consistently longer in certain parts of the country.  We continued root cause analysis until we got to something we could control (a "little x").  Turns out that by working more closely with architecture firms to identify requirements up front and to do the work right the first time allowed us more control and better performance.

No need to fire the project managers.