pmStudent

Sometimes we are throwing items over the wall to another team even when we don't mean to.

Let me explain.

5 months ago, I set up several meetings with one of my teams and a team we interface with. We squared away exactly how things would work between our systems and the design changed slightly because of what we learned.

Yesterday, I found out we had a problem.

How Did This Happen?

Even though everyone reviewed the design and agreed it would work well, there was a tiny, weeny problem which unraveled the whole design.

We just caught it yesterday, because the other team got around to implementing their code and were having problems. After several discussions we got on the same page, and I slapped myself on the forehead.

I Should Have Known

It's true, I should have caught this fatal flaw in our design back then. But then I remembered my email signature:

"Mistakes are usually caused by flawed systems; not bad people."

So what is broken in this system that could have prevented this problem?

This is What

Instead of just agreeing on the design and assuming it would function properly, we should have worked closely with the other team to build a prototype. A minimum viable product (MVP) - we would have discovered at once this fatal flaw.

As Eric Reise discusses in the Lean Startup, validated learning is the key to a startup company's success. While we are not a startup, projects definitely fall into that category. Had I followed this approach and asked the teams to collaborate to produce an MVP to validate our design change, we could have avoided all this. We would have known about the problem within a few days and resolved it with a different design.

That process also would have been even more collaborative, treating our two teams as a single team instead of throwing some specs over the wall, which is essentially what happened. Even if we all agreed on the specs in full, we didn't know what we didn't know.

So that's my recent lesson learned. I'm going to go sulk in the corner for awhile. Leave a comment to cheer me up.

Photo by Jessicizer

Most of the waterfall based project management thinking assumes that planners know enough about what the customer wants and estimate with enough accuracy to create a huge waterfall schedule way in advance.

True or False?

I certainly think it's true. A good example is large, predefined releases which go into low-level details. With predefined releases we are assuming that we know how project execution will play out well ahead of time.

My experience has shown me that we don't know, especially with large complex projects there are too many interfaces involved and decisions during execution that change the reality of what adds value from the customer perspective.

This creates all kinds of hassles regarding which scope goes into which release, which really doesn't matter when it comes to the end customer. Unless it's going to change the timeline for which these features or capabilities are available to the end user, it doesn't really matter which release it gets pocketed into.

What If?

So what if projects treated validated learning, a concept from Eric Ries' book "The Lean Startup", as the primary goal of the project? What if the primary purpose was to learn through iterations and then provide what the end-user wants, as opposed to just having the delivery of certain scope on time and on budget?

Could we set up a project management system in such a way that learning, validated learning, is the primary driver for project planning and execution, and still be confident that we are going to meet the projects scope schedule and budget requirements?

I haven't had an opportunity to do this myself fully from end-to-end on a large project. I've only been able to implement these types of principles within a subset of a larger project. So I can't say for sure. But I have heard from many people who are implementing projects in a Lean organization, using the type of approach that I'm talking about here.

What do you think about the importance of learning as a major part of your project management methodology? Deming's Plan>Do>Check>Act cycle is (sometimes) applied to PM processes, but how often is it applied directly to assessing the customer definition of value?  Please discuss in the comments below!

Like this? Share it!

I bet you didn't know it, but Wile E. was a project manager.

A specific breed of project manager.

So what lessons can we learn from our friend Wile E.? What made him so special?

Super Genius

You may remember, he preferred to use fantastic (and usually absurd) contraptions and elaborate plans to pursue his quarry.

His primary supplier was Acme Corporation, from which he procured complicated and usually ludicrous devices in the constant pursuit of success.

Two things usually happened with these devices upon implementation:

• The devices fail in spectacular ways (Kablooie!)
• The devices work, but operator error results in failure (Splat!)

But Why?

Why did our hero continuously end up smashed, blown up, or with a difference of opinion with gravity off a high ledge?

Like the time where Wile E. procured the Dehydrated Boulder, and then it became much larger than expected and crushed him?

Or the time he donned the Bat-Man outfit thinking it would make him fly, and it didn't live up to his expectations?

Teach Us, Mr. Coyote

So what do I mean, he wasn't a project manager, right?

No, not really. But he reminds me of many I know.

Wile E. Coyote relied on gadgets and tools, all of which either:

• Didn't work
• Worked too well
• Didn't fit his needs
• He didn't know how to use
• Introduced unnecessary risks

So thank you Wile E. for being the Tim Allen for my own project management career. You've taught me:

• Simpler is better
• Do only what adds value
• An ounce of execution is worth a pound of whiz-bang software
• No single solution fits all needs
• Risk management is freak'n important

So, what has Wile E. Coyote taught you? Leave a comment and let us know.

Like this? Share it!

Sometimes, we equate things that don't really mean the same thing.  Competence requires experience, but experience does not equate to competence.  I can infer experience from observing competence....but I can not accurately infer competence from a list of positions you've held.

Experienced ≠ Competent

We fall prey to common cognitive biases which lead us to believe that if someone is experienced, they are therefore competent.  It can trip us up when hiring for our teams.

Another aspect of this, and the more pernicious one, is that new professionals may lead themselves to believe that once they have some experience under their belt they will have 'made it'.  Complacency can set in after you've landed a job for instance, because you've tricked yourself into believing that simply holding that position makes you more valuable.

Certifications and Degrees ≠ Competence

The same goes for certifications and degrees.  Many people believe that holding a particular credential implies a level of competence.  Unless the credential is formulated specifically to assess competence, no such correlation is warranted however.  Organizations fall prey by hiring people and screening them on the basis of particular certifications or degrees.  Individuals fall prey by thinking they will have 'made it' once they get a slip of paper certifying them as 'master of the universe'.

Strive for Competence

Do not go after experience or certification as your primary goal.  They will come as a result of your journey towards competence.  

If you make experience, certification or degrees your primary goals, you run the risk of gaining those primary goals without acheiving a true level of competence for yourself.  These window dressings and indications of possible competence should only come about as a result of your journey towards something substantive; real competence.

It doesn't matter if you had the right answer or not; what matters is that you understand why it is wrong or right.  Seek to understand why.

Practical Ways to Target Competence

Here are some ideas you can use immediately to strive for competence.  Add your own ideas in the comments!

• Go beyond the material - In classes, use the standard curriculum as a starting point for your personal inquiry, not the whole of your learning.  Do research projects on topics that interest you, on your own, to quench your curiosity.  The same goes for workshops, e-Learning courses, webinars, and other project management resources.  The fact you are reading this is a testament to your commitment! 
• Ask people to catch you screwing up - Actively poll your team, co-workers, stakeholders, everyone.  Ask probing questions like "I was wondering if you had any ideas for how I could do [whatever] better next time?"  The more specific your question, the better.  If you just ask "How was that?" people will nod their heads and say "fine" almost every time.
• Earning PDUs is not the goal - Look, if you go seek PDUs for the sake of PDUs, you're doing it wrong.  Someone seeking competence in project management has more PDUs than they know what to do with.  Remembering to document them is the hard part.

Share this with your network

Dux Raymond Sy shares his 3 lessons learned while we were at the PMI North America Global Congress:

• Keep re-affirming customer expectations and priorities
• The difference between influence and interest - who is writing the check?
• Be a project facilitator and leader, not a control freak!

Lastly, Dux shares his thoughts about the conference.  Then of course I had to open my big mouth and add my opinion to Dux' second point about who is really influential on your projects.  From there we have some good back-and-forth conversation on related points and the acknowledgement of project management at high levels of government and corporations. 

(Notice the awesome Gantthead shirt I snagged while I was at the conference!)