Focus, find, and determine your root cause

But I’ve learned that the reality is that you will never be able to apply everything you’ve learned. This is because either it’s not needed or the organization can’t handle it. Every organization is different and has a different set of problems. What worked in one place, may not work in another.

What I’d like to talk about today is how to determine what is really needed process-wise when you first start a new project in a new culture. I’ve seen lots of Project Managers start new positions and want to apply everything they’ve learned from the PMBOK, only to actually slow things down and create inefficiency, and even, in some cases, bad will. There’s a stereotype out there about the ‘check the box’ Project Manager (PM). Someone who has all the correct process, but none of the wisdom to really correctly use process and tools to fantastic result. I don’t want you to become one of those PMs. I want you to become that indispensable, brilliant PM who analyzes the situation and correctly applies the tools.

You may be familiar with the Pareto rule. The Pareto rule says that 80% of effects come from 20% of the causes. In practice, this means that if you have problems on your project, most of them have the same cause or set of causes. It’s like there are ‘source’ causes for most of the problems that you see.

Success lies in addressing that 20%, the source causes, and neutralizing them before they balloon into 80% of your problems.

Here’s a process I’ve used to discover that 20%. Let’s call it the ‘The Real Need”  process. The goal of this process is NOT to apply everything in a model. The goal IS to apply the right process, in the right amount and to the right situation.

The Real Need Process:

Step 1: Force Yourself to Observe :

For people like me, sitting back and watching is really hard. But, I’ve fell flat on my face so many times racing to apply process, that I’ve finally learned to sit back and watch. I don’t mean don’t do your job. I mean, before you suggest brand new processes, watch and wait for a while.

Do this for about a week to a month – depending on the culture of your organization.

Step 2:  Analyze and Evaluate the Stream of Artifacts and Behaviors:

As you read documentation, or watch behavior, or read emails, start to breakdown what your next step would be according to the model. So for example, say you receive an email from a team member about how the client is angry with something. Most Project Management models would encourage that you take action. They would advise perhaps discussing the issue with a SME, maybe adding the issue to a list of risks to monitor. Let’s not forget potentially adding the issue into the change management system, and ensuring that the issue is added to action items for further discussion.

That’s a whole lot of behavior that you could do, and that the model predicts are best practices, because if you don’t do these things, the project can go into a lot of crazy directions, most of them unfavorable.

The key here is to document what the model says you should do, but not to do any of it, yet.

Instead, watch and see how the organization responds.

Step 3: Watch How the Organization Responds:

There is value in the repeated pathways of human behavior. Human beings are capable of developing success behaviors, which have been learned from past failures. When you first come into an organization, you probably don’t know those behaviors. Most of them aren’t documented. So what you may have interpreted as a failure behaviors based on your previous experience may in fact be a success behavior in the new environment.

Likewise, what the product/process model predicts as failure behaviors may in fact be success behavior in the new environment.

So, armed with your notes from step 2, watch the behavior and outcomes of the stream you observed in step 1. The organization will do two things; a) what you think they should do and b) what you think they shouldn’t do.

Step 4: Take Action:

For anything that is b) what you think they shouldn’t do, that winds up not causing further problems, strike that from your list of things to address immediately. This means that it’s not part of the 20% causing the 80% of the problems. In other words, the model (and your previous experience) may have predicted failure…but failure didn’t happen. Therefore, there’s some wisdom of experience in the behaviors of the organization that you should make a note to learn.

However, for anything that was a) what you think they should do that they didn’t do, and that led to a problem, focus in on that. That is your golden entre into solving problems. In that case, your instincts, and the model, predicted that a problem would occur. And because you’ve been learning, and have process and project tools at your disposal, you can rapidly suggest and hopefully implement a solution.

Conclusion

This isn’t a perfect way to get at all problems, but it’s a start. And it will prevent you from applying process where process probably isn’t needed. The idea here is to help you eliminate extraneous information by focusing on actual observed outcomes rather than on theory alone. This approach enables you to quickly find the failures, and use the theory for what it was meant for…project success.

by Michiko Diby, Blogger, Kosmothink

Related articles

• Radha.L, PMP: Project Management and ABC’s of life (pmhub.net)
• I’m Not Gonna Force Agile On You (magwep.wordpress.com)
• Process Improvement Programs – When You’re in Need of One? (corporategeek.info)
• Business Analysis Technique #26 – Scenarios and Use Cases (tapuniversity.com)
• Project Health Check : 5 serious project warning signs (tapuniversity.com)

Projects benefit from "health checks". Look out for warning signs!

Sometimes when working closely on a project, it is difficult to see the warning signs.  However, it is worth carrying out a project “health check” every now and then, to check for danger signs.  If you see any significant warning signals, then you might need to take some serious (and unpopular) corrective action.  Five such signals are discussed below:

1. Experts are ignored:

Projects that are in trouble may choose to selectively ignore concerns raised by experts.  Inconvenient truths tend to be “parked” or “explained away” without further analysis. Even worse, the commitment of those raising the concerns may be questioned.  This tends to have an extremely negative effect – morale of the project team is likely to suffer as they don’t feel listened to.  And even worse, they may feel disinclined to raise concerns in the future.

Organizational solution: Organizations and projects should encourage their experts to speak up.  It is generally better to know the “cold hard facts”, and every member of the project team should be encouraged to share their constructive concerns. This issue will cease if an organization proactively fosters accountability, whilst also fostering a culture of continuous improvement and learning. And remember: A project maverick is not a heretic!

2. Business cases are “re-worked”:

Business cases should be a central tool used by organizations to ensure that only profitable projects are run.  In some cases, other “hidden agendas” may be at play, and the project team might be asked to use some “creative licence” to make a business case look profitable.   This often happens in organizations where there is little accountability for the realization of project benefits.

Organizational solution: Organizations can stop this happening by encouraging and valuing true accountability, from project sponsor downwards.  The sponsor should be accountable for the delivery of benefits as well as the delivery of the project. Each project team member should be empowered to challenge decisions which seem to contradict the business case or scope.  Empowerment, accountability and integrity are the three key values that will prevent this situation from occurring in the first place.

3. Unclear objectives or scope:

One of the most serious warning signs on a project is a lack of scope.  If you start work on a project, and scope or objectives are not clear, then you are in for a rough ride.  This suggests that there has not been adequate attention paid to the foundations of the project, and in most cases it will be beneficial to step back and agree the scope.  If this doesn’t happen, there is a significant danger that the solution will be delivered in a way that does not meet expectations, and does not maximize return on investment.

Organizational solution: If scope or objectives are unclear, the only way to address this is to firm them up.  Good governance should stop this happening in the first place, but a project has slipped through then the project team should work to reach a consensus, and then move forward.  This might cost time in the short term, but it will save significant time in the long term, as it reduces the risk of misunderstandings and miscommunication over scope.

4. “Risks and issues” only exist on a log:

Embedding risk management techniques leads to more successful projects.  A significant project warning sign is RAID (risk, issue, assumption, dependency) logs that have not been maintained and are not being followed up.  This suggests that risk management is happening only “On paper”.   Each risk should be owned, and should have a defined strategy for dealing with it.  If this isn’t the case, then corrective action should be taken.

Organizational solution: The only solution to this problem is to ensure the project manager is actively controlling risks, issues, assumptions and dependencies.  If they are not, organizations should encourage and compel them to do so!

5. The project schedule doesn’t exist or is out of date:

A project and programme schedule should be a central communications tool.  Ultimately, this is a central tool that ensures everyone knows what tasks they need to complete, and what the deadline is.  A great way of carrying out a health-check on a project is to ask a random member of the project team where the project schedule is located, and ask them to show you a copy.  If they can’t, or if it is out of date, then you have uncovered a communication problem.

Organizational solution: Good governance and project discipline should ensure that all projects have a schedule that is fit-for-purpose.  Ask questions to ensure that a schedule is in place, and if it is absent then ensure it is created as soon as possible!

Conclusion

I see these warning signs as the “Big 5”, though there are many others that may surface on a project, and as change practitioners it’s important for us to recognise them and take any necessary corrective action.  Unfortunately, the corrective action is rarely palatable.  The most important thing we can do is to constructively challenge ourselves and our project colleagues, and ensure they are dealing with the cold hard facts.  We should escalate where necessary, and ensure that facts are not hidden and experts are not ignored.

Positive and proactive challenge and escalation is rarely popular, but is necessary to ensure that organisations get the best from their projects.  Good luck!

Have you worked on projects and seen these (or any other) warning signs?  Do you have any further examples?  I’d love to hear from you – feel free to contact me directly or leave a comment below.

About the author : Adrian Reed is a UK based Lead Business Analyst, author, speaker and qualified practitioner of change. If you enjoyed this article, you can follow Adrian on Twitter or read his personal blog.

Related articles

• Early Signs your ERP Implementation is failing, part 2 (boverstreet.wordpress.com)
• There is no ‘I’ in Team: The Basics of Teamwork (noupe.com)

You may not see the mountain top, but you can see the next step!

The essential concept of progressive elaboration is that organizations, teams, and people do not have to have all the pieces and parts fully known before beginning. Don’t get me wrong, having details is important, but not for everyone.

This approach fits very well with the change driven methodologies of Agile and Lean Software Development.  Communication needs to be done in concise and clear bursts. Understanding the big picture and the project outcomes are more important, the details can be elaborated as the project progresses.  Here are some ways to make sure your communication supports that effort:

1. Make sure there’s a unifying theme for all the pieces and phases of your project — this allows your audience to stay connected and know how this month’s effort supports the previous one and the one from three months ago.
2. Writing style and grammar should not fall off the progressive elaboration list — whatever is communicated, it should be well written and focused on the audience.
3. Writing is an exercise in progressive elaboration in and of itself. Do you have an article to write, a website to update, a presentation to prepare? Start with an outline and then elaborate on the details as you progress through development.

Remember, if you wait for ALL the details you may never get started.

Related Articles

• Book Review: Leading Lean Software Development (h3rald.com)
• What is Trans-Scrum? (codemonkeyism.com)
• Book Review – Extreme Programming Explained (elegantcode.com)
• Scrum is not about engineering practices (codemonkeyism.com)
• Eight steps to achieve ‘lean IT’ (zdnet.com)

Let the celebration begin - your virtual team project was a success!

Prove it

Maneuvering the political gauntlet through artful conversation and word-smithing will not resolve conflict.  Nothing will stop conflict the like graceful execution and control of a project that leads to on time, on budget completion.

This is the area where the project management fundamentals are a focal point.  Earned value may not be glamorous, but it is a precise and proven way for communicating good and bad information to all stakeholders in a factual way.  Also ensure your project allows for real milestones no more than two weeks apart.  Separate long duration projects, greater than six months, into discrete phases.  Finally rely on shorter chunks of communications – 15 minutes every day is better than a 2 hour conference call/webinar on Friday.

Triumph

This step is targeted at the team with some horn blowing to stakeholders as well.  Use post milestone or project reviews as learning experiences and times of celebration.  As a project succeeds, remember to include as many people as possible.  Inclusiveness in times of success builds bridges in times of difficulty.

Milestone celebrations are a group experience.  The role of project manager also requires giving one on one feedback.  Feedback is best accomplished by focusing on tangible results of performance.  Plan for evaluating performance during the project’s planning phase.  Define up front the quality, quantity and timeliness standards for the project and individual team members.  Use those pre-defined standards for an objective benchmark.

What your team's pulse rate?

While environmental IQ through stakeholder’s analysis addresses the outside / in part of the equation, evaluate the team’s pulses addresses the inside / out.  When the two are balanced through an equal amount of attention and thought, then the conflict potential is lowered.

There are two steps for knowing a teams pulse.

The first step is start by helping the team get to know each other better. There are several useful tools which help a team know each other and work together better.  Three recognized ones are:

• The Keirsey Temperament® and Myers Briggs (EI / SN / TF / JP).  This is the oldest and most recognized personality and group fit assessment (see www.keirsey.com )
• The DISC® assessment which allows an individual and team understand their natural and adaptive personality.  There are several available online.
• The Strengths based assessments such as ones offered by Marcus Buckingham (see http://www.tmbc.com/), Curt Coffman (see http://coffmanorganization.com/)  or Clifton StrengthsFinder® developed by The Gallup Organization.  (See www.strengthsfinder.com ).

Absent those tools time spent learning about team members, inside formal meetings as well as through informal activities has a significant payoff.  A project manager should know each team member’s strengths, weaknesses, competencies, preferences and obligations.  Do not assume a job title or role translates into a competency (although it is desirable if it does).

The second step is to ensure a clear, consistent and shared mission exists.  Project charters may have little or no input from the team assembled to implement the charter.  Take time at initiation to ensure understanding of the project’s purpose by all team members.  Do not only rely on the organization’s traditional workflow and communication procedures to provide sufficient communication coverage.

What's over there?

We have IQ, there’s Emotional Intelligence (EI) – I say we add  EQ – environmental intelligence based on applying that Emotional Intelligence to what’s going on with stakeholders.

A quick recap, a stakeholder is someone who has a professional interest in the outcome of a project.  That interest may be acknowledged and formalized – corporate board, supervisor, project team and internal or external customer.  It also may be unacknowledged and informal — parallel project teams; teams up or down stream of the project’s production flow (e.g., Shipping), or through a functional group associated but not directly affected (e.g. accounting or marketing).

A stakeholder’s analysis is typically an informal data gathering process.  Perform it during a project team meeting.  The following three steps are recommended:

Identify who will be impacted by the project inside and outside the organization.  It is helpful to draw it on dry erase board or flip chart in a counter clock-wise fashion with the candidate project at 3 o’clock.

Identify outcomes, desirable (+) and undesirable (-).

Identify how often a group should receive information.  Information gleamed here feeds into the project’s responsibility assignment matrix (RAM) or RACI.

Why is this helpful for managing conflict in virtual teams?  Understanding the information and communication needs of stakeholders is critical in all teams, in virtual teams the opportunity to pick up informal, non-verbal ques is far less.  So a project manager needs to be much more deliberate to unearth potential problems

Related Articles

• Virtual Teams – Conflict Resolution – Prepare (tapuniversity.com)
• Virtual Teams – Conflict Resolution, Risk Assessment (tapuniversity.com)
• 5 Common Types of Conflict Found in Project Teams (brighthub.com)
• IQ or Wits Check; Fallacies and Cognitive Biases from Game in the Brain (gameinthebrain.blogspot.com)
• 10 Typical Activities of a Project Development Team (brighthub.com)
• 10 Ways to Resolve Conflict Between Project Team Members (brighthub.com)

Just a little bit of risk that needs to management

Step Two of Resolving Virtual Team Conflict is to treat it as a potential risk.  The advantage of looking at team conflict as a risk is it’s an easier to say “hey let’s treat team conflict as a risk element, something that might happen” rather than “gee, we’re conflicted and at each others throat, upper management help!”

The following table is taken from a real life project at a dot.com company in 2001.  As with other projects at this start-up, the project was ripe for conflict and full of risks.  While the technology as leap frogged ahead in 10 years, the issues with virtual teams remain.

The purpose of this project was to deliver an innovative solution to a large software company.  It required an “all hands to one side of ship” approach using brute force to complete.

Unique was that resources were distributed across three locations, Silicon Valley, Shanghai and a Midwest Operations Center.

Conflict was included as a potential risk element and mitigated through structured, consistent communication (via conference call, Internet chat, web conferencing and shared document store).  This approach helped achieve an ambitious and high risk, release to market.

See Table 1.

Table 1.  Risk assessment with conflict element

This may be you, right now. Or if not, in your near future!

Virtual teams are geographical dispersed teams (GDT) who are formed for a variety of reasons.  Sometimes the virtual team is formed as a result of mergers and acquisitions (M&A), or a collaboration among organizations may trigger it, perhaps a key employee moves or a company wishes to get some “boots on the ground” in a new city.  Regardless of the motivation, virtual teams are a given in a dynamic global community.

The Fourth Edition PMBOK references virtual teams as a tool and technique for Acquire Human Resources (Section 9.2).  That single tool and technique can produce a wealth of questions for the PMP exam.  From conflict, to communication overhead, twenty-four hour work cycle and requirements gathering challenges – there’s a long list of topics to discuss and validate.

Virtual teams are a practice area for TAPUniversity.  We have studied them and helped others become proficient in managing them since 2005.  Frequently traditional management wisdom does not apply and may even back fire.  Virtual teams also have proven a sticking point for the Agile SCRUM movement, which, in its initial manifesto, had co-located teams as key principle.  Over the next few weeks we’ll dig deeper and share more about virtual teams.

Please share your experiences as well.  What’s worked well?  What hasn’t?  What’s changed for you in the last ten years in working with virtual teams?

Don't let a plate or estimate fall!

Schedule (Activity Duration or Activity Resource) and Cost estimating are two lynch pins for business analysis and project management. The most common estimate techniques are: analogous, bottom-up, parametric and three-point – PERT.

For those pursuing a CBAP® or PMP® how to use them and whether those are mutually exclusive can become a bit confusing.  The hundreds of exam banks for the PMP® exam often seem to force a PMBOK® based exclusion (see Sections 6.3, 6.4 and 7.1).  That is not accurate.   The estimates for schedule and cost are in practice used together and also not presented as mutually exclusive on the PMP exam.

Now for a quick review of how the four estimate types might work together.  Let’s use a swim meet as an example.

• Analogous estimate - just like the root word analogy implies, analogous estimates are based on a previous project(s) within the organization.  This estimate is often the earliest and most convenient one to gather.  Because of that it is often used to justify a project and for project chartering.
  Example when I help conduct a swim meet we have an intuitive sense of how long a meet of 50, 100, 150, 200 or 250 swimmers will take.   My role is typically whatever is needed and most often starter, referee or stroke and turn judge.
  For a meet we conducted Saturday – based on 210 swimmers for over 70 events with a 20 minute break – our analogous estimate 
  

  Lining up swimmers is like herding cats into the water.

  was 8:30 a.m. to 3:45 p.m.  The various swim meet official team members were a bit nervous when official entries received by Wednesday were 50 more than anticipated.  So our analogous estimate that had been 8:30 a.m. to 2:00pm was revised upward.  Adding a bit to our anxiety was the threat of winter storm (two teams were traveling over 50 miles).

• Bottom-up estimate – this estimate gathers cost or schedule from the resources or subject matter experts (SME) involved in performing the activity.  The idea is rooted in quality management – those that do the work really  have the best idea of what is involved.Using the swim meet example again, we ask coaches, those that help line up the swimmers (clerk of the course), time (timers), judge and officiate  how long each stroke (free, back, breast, butter fly, individual medley and relays)  might take and then use those estimates alongside seeded times for each swimmer to create a schedule.
  For that Saturday meet – our bottom up estimate was 8:30 am to 2:52 p.m.
• Parametric estimate - this estimate looks at aggregate estimates from across an industry.  A treasured pocket-book of mine is the Wilson’s pocket estimator (circa 1985).  It’s full of construction estimates for time and resource load, from plumbing to drywall.  I used it for estimating paint jobs during my undergraduate work.  Visiting the swim meet example. the USA Swim Association and YMCA swim governance offer guidance for indoor and open water swim meets.
  For that Saturday meet the YMCA swim guide estimate was 8:30 to 3:30 p.m.
• Three-point/ PERT (program evaluation and review technique) - this estimate typically is used with the other three techniques to develop a pessimistic, most likely and optimistic schedule per activity.  We did not apply this to every activity (event/heat) for the meet.  I did do a quick three-point for the 25 yard events (where timers move from one side of the pool to the other).  The timer travel time took anywhere from 90 seconds to 4 minutes (quite a range) with the most likely or mean travel time of 3 minutes 10 seconds.  My quick 3-point estimate was 2 minutes 53 seconds.

SWIM MEET Actual – the meet went from 8:30am to 3:18 p.m or within the estimate range. The meet was ahead of the bottom-up schedule in the early morning due to combining two 500 yard events into one.  The meet fell behind the bottom-up schedule in the late morning as the 25 yard events were conducted (a dummy activity or lag for timer travel time was not entered).

So what?  As you incorporate the estimating techniques, incorporate all four if possible.  Analogous and Parametric estimates are found by asking someone in your organization (analogous). Nimble use of “Google” will help find your industries Parametric estimates (e.g. COCOMO for software development or Wilson’s estimator for construction).  Bottom-up involves talking with key resources and getting a sense of who will perform that activity for your project (for example a new team member will not produce as quickly as a 7 year SME).  Three-Point / PERT can be used selectively for higher risk activities or ones that you want that second look.