pmStudent

You may or may not be familiar with Shigeo Shingo’s identification of types of waste. Waste is essentially any activity which does not add value to the products being produced.

Even if you are not strictly working in a Lean methodology on your projects, these are applicable to all projects and environments, and can be avoided or mitigated if they are acknowledged.

I’ll provide my perspective from managing project teams doing software development for image data processing for a remote sensing satellite mission. If you are doing software development much of this will sound familiar, and even if you manage other types of projects I’d bet you’ll start getting ideas for your own domain.

I think you’ll be surprised at what you find when you start looking for these on your own projects, and using 5 Whys and other techniques you’ll be able to attack many of them and make your project teams more productive.
 

Defects

When the product doesn’t do what it needs to do, this is obviously a form of waste. There is one type of defect we call ‘bugs’ in software development. This is when there is an internal defect in the way the system works, or even just that it doesn’t meet a requirement.

There is another kind of defect though, and it’s probably the biggest form of waste in my book. It’s when you’ve produced something the customer doesn’t want. When I was a developer, I participated in creating several products that met our requirements, but when we launched them no one used them. Why?

Primarily, this was due to either a ‘pet project’ by some director in the organization who dreamed up this great system without checking to see if it would actually add value to anyone’s life. Additionally, the waterfall method without proper iteration means that by the time a product is delivered, it’s no longer what the customer wants or the interpretation of the requirements was drastically different. That’s why I love lean/agile methodologies where continuous customer feedback is critical, iteration and change is expected and encouraged.
 

Over-production

With physical goods this one is easy to see. Picture a warehouse full of materials because they were ‘cheaper to produce in bulk’. Producing something before it’s needed or producing too much of it is waste.

With something like software development it’s a bit different. Overproduction can take the form of producing elaborate systems to handle potential issues that are very unlikely, and could be handled manually by operators rather than trying to build the perfect system to automatically handle every little eventuality you can think of. There is maintenance of code to consider, and the time spent designing, developing, and testing code weighed against the time it will likely take for operators of the software to manually identify and fix these issues.
 

Transportation

In Lean manufacturing, transporting goods from an overseas supplier is often seen as waste when a local supplier can provide them, even if it costs more. The local supplier can be more responsive with shorter lead times, so you have less need to predict future demand and store input materials or finished goods taking up warehouse space.

With software projects this is largely mitigated in terms of moving product around, but can apply to moving people around. Traveling more than needed to meetings in other cities or even just the meetings we all have on a daily basis is a form of wasted potential productivity.
 

Waiting

Any people, parts, or other items waiting for the next step in being complete are being engaged in a form of waste.

With software development this can be the time between when coding is complete, peer reviews of the code take place, documentation is updated, and testing is performed. The more time between these steps, the longer it is going to take for the team to get re-oriented. I’ve seen peer reviews or or documentation take 10 times longer than it needed to, because the developer had to go back to the code they had written months ago and familiarize themselves with it again.

All of the queue times between steps from ‘begin’ to ‘complete’ are waste.
 

Inventory

With physical goods this is clearly warehouse space getting used up by goods just sitting there doing nothing.

With software, this is the list of features you’ve finished but not yet deployed to a customer. There is potential value being wasted because it has not been deployed. It also means it will take longer for you to find problems because you are delaying the crucial feedback mechanism from your customers.
 

Motion

This is pretty much what I said under the transportation heading. I’ll add to what I said there to mention that a huge source of waste on projects are meetings. If you or anyone on your team ever attend a meeting you can’t either 1) contribute to or 2) benefit from then it’s a form of waste. That is lost productivity that will never be regained.
 

Over-processing

This is essentially gold-plating. Anything you do beyond what adds value to the customer is wate. Even if you think it’s a whiz-bang cool feature, if it doesn’t get used it doesn’t add value and therefore is a form of waste.

So look around. What forms of waste can you start avoiding?

If you've done any work in systems or software development, you've probably use Lines of Code (LOC) before.

Either as an estimation tool with something like COCOMO, or as a retrospective gauge of the work your team did on a particular release of software with added/modified lines of code.

It's All Bull

Lines of Code as a measure of productivity or as an estimation tool is nearly meaningless. But it's something quantifyable and so people (especially managers) grab hold of it like a life raft.

I feel very similarly about Function Points, and I think both of these try to simplify something that is too complex for a one-size-fits-all method.

Here's the problem with equating LOC with productivity, effort, or estimates:

• An engineer may spend several hours on a block of code less than 20 lines, and the next day spend the same amount of time on writing 1000 lines of new code. Both are completely valid, and reality. It's all a matter of context.
• A system with 50k LOC that does the same thing as another system with 100k LOC is twice as good as the 100k LOC system, I'd argue. The lower LOC system is refactored better, less complexity for the same functionality, and easier to maintain.
• I re-wrote about 40 lines of code a few weeks ago (this is rare, I usually don't do much programming any more) because of a performance issue. The end result was half the code, and a roughly 450x improvement in performance (returning records in 400ms from a database instead of the ~3 minutes it was taking). I spent an hour reducing LOC to improve the system.

Now tell me how LOC can possibly be a global proxy for value or productivity?

User Stories or Features

I think the best proxy we have is user stories or features completed, provided and assuming they are valid. It's really just as valid a measure as any other arena like construction...you have assumptions that requirements were elicited properly and you are actually building what the customer wants.

What do you think? How do you measure or estimate productivity/effort on your software projects?

Taking small risks and failing fast is the best risk management strategy around.

Let me explain..

Vallidated Learning Through Small Risks

I identify strongly with the Lean Startup concept of validated learning, and I think every project is just like a startup. Especially in the beginning, validated learning is much more important than just cranking out a product for the sake of it.

If you think your customer will love something and you have the capability of demonstrating it in a visual way very quickly, do it!

The learning you gain from the experience, even if the customer hates it, is worth it.

Avoid Creating Your Own Big Risks

Too many project managers create their own large risk of producing a product no one will use.

That's the biggest risk of all.

Trying to avoid the small risks.  Being afraid to make mistakes. Being afraid to be wrong.

These are the attributes that result in big risks. And the project manager induces these herself.

What ways can you take small risks proactively to learn more quickly and avoid the big risks?

photo by Explore The Bruce

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