pmStudent

I'm a Mechanical Engineer having 4+ years of experience in engineering projects. In addition, I have 3+ years of SAP Project System experience. Presently I'm working as a SAP PS consultant. I want to expand my career in project management field.. Seek your guidance.... -Pratik

Pratik, it’s all about separating yourself from the pack.

Networking is powerful, because when people who know you are good refer you there is a trust factor that goes with it. Don’t just send your resume or CV and a cover letter. Make phone calls. Ask someone in the company what the big challenges they face are, and come up with a solution to them.

Find ways to demonstrate your ability to add value to the organization.

Stepping Stones

Project Controls may also be a good stepping stone into a role managing the type of projects you want to manage. In a role like project controller, scheduler, or coordinator you will gain experience of the 'other side' of projects from the technical side you already know.

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

I received a question from someone dealing with a discrepancy between how EVM reporting has been presenting progress versus actual progress.

Essentially, the scope and cost of the project has increased, partially through estimation problems and scope changes over time.

However, it appears they are still reporting against the same Performance Measurement Baseline (PMB).

The sooner you can transparently communicate with key stakeholders, the better. 

Josh,
Does re baseline mean:
Drop in progress percent complete, say reporting 80% in revised scenario versus previously reported 90%??
If not, then what does this rebaseline actually mean?

A rebaseline only happens when everyone agrees there has been a significant change in scope, cost, or schedule.

What is the fiscal responsiblity of the project manager anyway?

Are we just supposed to deliver projects within budget? Is that the extent of our responsibility?

No

Look, there are plenty of ways to manage projects.

Some of them involve a ton of paperwork, and some involve just what adds value to the end user.

Some build in a certainty of tons of rework by planning for detailed design months or even years before development, and some plan on progressive elaboration after formulating a solid start-up plan to get a clear idea of the end goals and project constraints.

Ask Yourself

I challenge you and myself. Let's ask ourselves as we go about our working day to stop and think about our own activities and those of our team members.

Do those activities add value? Which activities could we do without or do better. Are we getting the 'bang for our buck'.

Do we run on our fuel of incoming investment dollars like a shiny new hybrid compact sedan, or a gas-guzzling Hum-Vee?

And in the final analysis, does your project either 1) save money for the organization or 2) make money for the organization? Do you measure ROI in a rigorous way? If not, how can you even tell?

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!