Project Management

Throwing It Over The Wall

From the pmStudent Blog
by
Ranting and raving about project management and systems engineering.

About this Blog

RSS

Recent Posts

The Problem with Project Management

The Problem with Project Management

The Problem with Project Management

LinkedIn Recommendations Are Easy

The Catch-22 of Project Management Certification and Experience

Categories

Agile, Career Development, Certification, Change Management, Communications Management, Cost Management, Documentation, Earned Value Management, Education, Integration and Test, Kanban, Leadership, Lean, Lessons Learned, Methodology, Misc, Multitasking, New Project, Operations, Planning, PMP, Productivity, Professional Development, Project Estimation, Project Leadership, Quality, Requirements Management, Risk Management, Schedule Management, Scope Management, Software, Systems Thinking, Tools, Video, Work Breakdown Structures (WBS)

Date

linkedin twitter facebook Request to reuse this  

Categories: Lessons Learned


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


Posted on: January 31, 2012 05:28 PM | Permalink

Comments (0)

Please login or join to subscribe to this item


Please Login/Register to leave a comment.

ADVERTISEMENTS

One man can be a crucial ingredient on a team, but one man cannot make a team.

- Kareem Abdul-Jabbar

ADVERTISEMENT

Sponsors