Showing posts with label Lean. Show all posts
Showing posts with label Lean. Show all posts

February 4, 2014

The 80/20 Rule

The phrase 80/20 rule gets used by a lot of pundits to describe "that 80 percent of all our results in business and in life stem from a mere 20 percent of our efforts."

The original 80/20 rule came from the Pareto Principal which talks about root cause analysis - 80% of effects come from 20% of the causes. 

My 80/20 Rule 
It has been my experience that the first 80% of any task or project takes 20% of the time - and - the last 20% of a task or project takes 80% of the time.

Here are some examples:
  1. Trade partners (construction subcontractors) will get about 80% of the work done, leaving 20% to be found by others. 
  2. Students will prepare for about 80% of the test material, hoping the last 20% will not be on the test. 
  3. Kids will clean 80% of their room, and hide the last 20% under the bed or closet.
  4. Team members are gung-ho to finish the first 80%, but have other priorities at the last 20%. 
Why Does the Last 20% Need the Most Attention? 
It needs the attention because that is where the 'finish' zone is. The finish zone is where all the: 
  • Synthesis is done. 
  • Customer receives the value of the service. 
  • The job /task/project is DONE and COMPLETE. 
The last 20% may be the hardest part, but it is worthy of the same attention and dedication and thoughtfulness as the first 80%. Here are some strategies: 
  1. Understand the last 20% will be harder and give it the appropriate amount of project time. 
  2. Give the effort that is required. It is hard being the last 20% team member, but I say it is rewarding to be a part of the 'finishing' team. 
  3. Use more checks and balances so the last 20% is not so much about fixing things (see Last Planner, Agile methodology, and writing effective requirements.)
Finally, the pundits say "that 80 percent of all our results in business and in life stem from a mere 20 percent of our efforts." I think here they are talking about most of our time in life and business is not spent in productive pursuits. How much time do we spend trying to find that email the boss sent out that he/she wants an answer on? Too much time, I agree.

A job worth doing is worth doing well (and to completion). Planning well and good execution are the keys to success. 



David Haynes, NCARB, PMP, LEED AP
Ideate Director of Consulting

David is a Registered Architect, Project Management Certified Professional, who previously had his own architectural practice and was President of a commercial design-build construction company for 15 years. A graduate of University of Arizona, he has worked as an Architect, contractor, developer and as a national construction manager for a national retailer. David currently provides business process analysis, virtualization and change management solutions for AEC clients across the United States involved in the design and building industry. Follow David on Twitter: @dhaynestech 


Get it. Know it. Use it.


This post was originally published on David’s blog Connecting the [Data]… 

November 27, 2013

Negotiate - What you do every day

 "Negotiation is a dialogue between two or more people or parties" (Wikipedia)

Just as all of us who work are part of a sales organization, ALL of us who interact with others are involved in negotiation. However, negotiation has gotten a bad reputation, based upon the 'win at all costs' that exist in today's hype-competitive business environment. There seems to be a notion that negotiation is about getting the other side to surrender, as expressed in this quote:

"Negotiation means getting the best of your opponent" - Marvin Gaye

I believe something different. I have some experience in negotiating - with a weak position, with a strong position, out of necessity, as the 'hired gun', and even when I desperately wanted to be anywhere else but at the negotiation table.

Those who manage people in a business environment, negotiate with their team members all the time. Team members negotiate with their team leads also. It is a two way street.

Here are some things I have learned - maybe these observations will help you in your next negotiation.

  • If the other side cannot give you what you desire (such as ordering a BigMac at a Starbucks), all the negotiating skills, yelling, and desk pounding will not get a resolution. Look at your expectations (http://connectingthedata.blogspot.com/2013/08/are-you-asking-right-questions-service.html). "You cannot negotiate with people who say what's mine is mine and what's yours is negotiable" - John F Kennedy. 
  • Facts sometimes get in the way of emotions. This is often my fatal flaw - I think facts should always rule, and in some negotiations, facts just get in the way. Let the other side get their emotions 'expressed'. "The most difficult thing in any negotiation, almost, is making sure that you strip it out of emotion and deal with the facts" - Howard Baker.
  • Some say that being dispassionate is the key. I have been in too many negotiations, where one side did not care - I promise you, there never was a resolution until each side cared about the outcome. Each side may have different reasons for a resolution, but they wanted a resolution.
  • Try to understand the other person's position. Not just the technical aspects, but the social, economic, and cultural side of why/how you are negotiating. 
  • Leverage is the key and the danger. If I leverage you, by withholding money, to complete a task well, what are the chances that you will be 'all in' (http://connectingthedata.blogspot.com/2013/10/are-you-all-in-or-just-surviving.html). In my mind, leverage is the gentle balance between forcing and coaxing. It is crucial that the harder the leverage point, the clearer the path to the other side getting what they desire.
So, where can we get some guidance?  I personally like the "GROW" process (http://en.wikipedia.org/wiki/GROW_model):
  • Goal - where do we both want to be at the end point. If your goal is to 'kill' your opponent, you can quickly see why these negotiations never work. 
  • Reality - this is usually where facts can get in the way. Maybe the 'reality' is not only about the facts, but how people feel about those facts.
  • Obstacles/Options - Overcoming obstacles is the key to a good negotiator. What is the 'roadblock' that is stopping a solution. In lean thinking, it is almost always systematic roadblocks that cause problems (waste or error). I have seen the an obstacle to be as simply as "I want to get paid 10% down to buy materials", and I have seen negotiators say "no", because they had leverage.
  • Way Forward - Actions steps moving forward.
The GROW process also works for conflict resolution and mentoring. If you are not familiar with the process - check it out. (http://www.mindtools.com/pages/article/newLDR_89.htm).

"The most important trip you may take in life is meeting people half way" - Henry Boyle



David Haynes, NCARB, PMP, LEED AP
Ideate Director of Consulting

David is a Registered Architect, Project Management Certified Professional, who previously had his own architectural practice and was President of a commercial design-build construction company for 15 years. A graduate of University of Arizona, he has worked as an Architect, contractor, developer and as a national construction manager for a national retailer. David currently provides business process analysis, virtualization and change management solutions for AEC clients across the United States involved in the design and building industry. Follow David on Twitter: @dhaynestech 


Get it. Know it. Use it.

This post was originally published on David’s blog Connecting the [Data]… 

November 12, 2013

Commitment to Change

We all believe that we are good at 'change'. We are 'champions of change'. But is that really true?
  • Why are people, in general, so resistant to change?
  • What does it take to implement change (personally or professionally)
  • What is the one key attribute?
RESISTANCE TO CHANGE
There are multiple phases people go through during change:



These phases are inevitable, it is only our external response we have control over.

WHAT DOES IT TAKE TO IMPLEMENT CHANGE

In every successful change implementation it takes three key elements, without these keys, the change is doomed at least to a bumpy road, and probably to either under-achievement or failure.

  • Upper management buy-in. This cannot be under estimated. Without executive buy-in, the change is destined for stalling. Mid-level management will test the business resolve of upper management and can smell weakness in a heartbeat. Momentum is lost, and delay is what happens. 
  • Have a plan. Seems obvious, but much of change happens without a fully resolved and documented plan. Firms implementing change often say 'we are really smart and we will figure it out'. This is misguided and often leads to delay of change. Hire a qualified consultant, with resources to bring to the table, and give implementation consultant the input needed for a plan that is both reasoned and documented.
    • What problem are we trying to solve?
    • What are we willing to do to assist?
    • What is our corporate culture and what works best for our type of company (not based upon budget, but upon other successful change).
A project requires a new software to be implemented. The existing software opens in 1 second. The new software opens in 2 seconds. The metric says 100% decrease in performance (2 seconds vs. 1 second). The Condition of Success is the user should not notice the change from using existing software to new software.  

The problem is that metrics (numbers) can be manipulated to either forecast failure or promote success.  Metrics are not the only predictors of change success.  A defined and agreed upon Condition of Success will be a better indicator of a successful implementation than metrics.

ONE KEY ATTRIBUTE
What is the one crucial part?. Commitment. Commitment by all the parties involved, the customer and the consultant. Commitment is more than "I will pay you if you provide this for me". Commitment is the dedication of management buy-in, consultant time and effort, customer involvement and response, and dedication to conditions of success.

Unless Greek mythology Sisyphus is your hero (http://www.merriam-webster.com/dictionary
/sisyphus
), look at your next change implementation from a different perspective.



David Haynes, NCARB, PMP, LEED AP
Ideate Director of Consulting

David is a Registered Architect, Project Management Certified Professional, who previously had his own architectural practice and was President of a commercial design-build construction company for 15 years. A graduate of University of Arizona, he has worked as an Architect, contractor, developer and as a national construction manager for a national retailer. David currently provides business process analysis, virtualization and change management solutions for AEC clients across the United States involved in the design and building industry. Follow David on Twitter: @dhaynestech 


Get it. Know it. Use it.

This post was originally published on David’s blog Connecting the [Data]… 

November 7, 2013

When am I done? Why is the customer unhappy?

Within all agreements there is the expectation that the customer will be satisfied. This basic tenet of contract law is assumed, but rarely documented well in the contract or agreement. How will we know if the customer is satisfied? When things go bad in a project, more times than not, the problem starts out with the client feeling that their needs are not being met - in other words unsatisfied.

Lean thinking has a concept called Conditions of Satisfaction (COS). This concept applies to any endeavor/project, whether it is a construction project, IT project, or any other customer-based service.  Conditions of Satisfaction is defined as:

Criteria by which the outcome of a contract, program, or project may be measured.

What does a Condition of Satisfaction include:

  1. What are the expectations of the customer?  How often do we assume that or project/service meets those expectations. 
  2. Have the Conditions of Satisfaction been documented/validated/verified and confirmed by the customer? 
  3. Are the Conditions of Satisfaction(s) defined in a actionable way?

These actionable items require two key elements:
  1. Actionable items solve project requirements. The requirements that the project must solve needs to be written in a clear and defined way.  Each requirement shall be stated in a precise manner, and solve only one issue at a time.  There may be multiple requirements in a project. 
  2. The requirements also need to describe what the customer is to do.  Some call this NIC (not in contract), but I believe that Conditions of Satisfaction needs to include what the customer is providing.  I have found the best projects are one where the customer is fully engaged in the process, including providing elements of the completed project.  This dual, written commitment makes for a better partnership between the customer and the provider.
During the project, these COS requirements are reviewed at every meeting, and special attention is paid to them prior to the completion of the work.  A project cannot be complete without agreement on completing the Conditions of Satisfaction requirements.


David Haynes, NCARB, PMP, LEED AP
Ideate Director of Consulting

David is a Registered Architect, Project Management Certified Professional, who previously had his own architectural practice and was President of a commercial design-build construction company for 15 years. A graduate of University of Arizona, he has worked as an Architect, contractor, developer and as a national construction manager for a national retailer. David currently provides business process analysis, virtualization and change management solutions for AEC clients across the United States involved in the design and building industry. Follow David on Twitter: @dhaynestech 


Get it. Know it. Use it.

This post was originally published on David’s blog Connecting the [Data]… 

November 4, 2013

Big Red Button vs. Elephant Eating

When a consultant is asked how to solve a business problem, the customer/client is often interested in an over-arching, one big button solution.

This approach has two problems:

  • Trying to solve problems with the 'big answer' denies an improvement  loop, both by the consultant and by the process itself. 
  • It is very hard to solve any problem with just one answer.
There is an old saying "How do you eat an elephant? One bite at a time". It is really true. So what are the key elements:
  •  Start with baby steps. This is the one bite at a time to eat an elephant.  One of the advantages most overlooked is that this method (a stepped approach) reduces anxiety those affected by the change will feel. 
  •  Adjustments can be made.  If everything is defined, and set in stone, the implementation team (consultant and customer) will be reluctant to modify the process.
  • But the key issue is:
                      CONTINUOUS IMPROVEMENT

Continuous improvement is one of the main tenets of lean thinking, lean services, etc. W. Edward Deming, pioneer in the field of Lean, proposed that feedback from a process and customers must be evaluated against goals. This feed-back loop allows for course adjustment, realignment, and even discovery of a different problem statement. With feedback, a better process is possible.

Eat the elephant one bite at a time and provide feedback of each bite.



David Haynes, NCARB, PMP, LEED AP
Ideate Director of Consulting

David is a Registered Architect, Project Management Certified Professional, who previously had his own architectural practice and was President of a commercial design-build construction company for 15 years. A graduate of University of Arizona, he has worked as an Architect, contractor, developer and as a national construction manager for a national retailer. David currently provides business process analysis, virtualization and change management solutions for AEC clients across the United States involved in the design and building industry. Follow David on Twitter: @dhaynestech 


Get it. Know it. Use it.

This post was originally published on David’s blog Connecting the [Data]…