Do you want to learn more about project management as a discipline and career?
Josh Nankivel helps new and aspiring project managers reach their career goals through volunteering, writing, and project management training. He has a broad background of managing small and large projects across several industries including aerospace, financial services, and telecommunications.
Do you manage your projects with the perspective of the full life cycle of the product(s) you are creating?
I’ll bet the answer is no. That’s what my answer is too. I think I fail at this as much as anyone.
Traditional project management practices have led us to focus on the short term impacts of scope, cost, and quality.
Initial Scope
This is probably the place we do best at identifying and trying to quantify the full life cycle costs of the product. There is at least a small section of the projects out there with a strong initiation phase that consider life beyond the final project milestone.
When we don’t, we can end up creating a product the customer is happy with today, but becomes the bane of their existence two years from now. Some examples of life cycle considerations:
Maintainability of code
Flexibility for future updates as technology progresses
Ease of interfacing with other systems
Sponsor changes - when your sponsor is replaced by someone else, does your product still add value to the business?
Total cost of ownership
Change Control
When your project deals with a change request, what are the factors taken into account? Is it just a matter of how many hours or dollars it will take to implement the change?
Are you also estimating the impact in operations of the change? What life cycle considerations are you taking into account?
Documentation
When you decide to add another document into the mix or just on the initial number of documents required for your project, do you figure in the total impact for maintaining those documents across the entire product life cycle?
Code
If you aren’t doing automated software builds and automated unit testing of code, have you figured in the lifetime costs during development and in operations of that decision?
Have you figured in the risk of deploying code into operations that has only rudimentary testing procedures?
Processes
With all of the many processes that occur on your project, what’s the difference between their optimal state and the current state? Does saving an hour a day collectively across the project team because of a process improvement make a difference?
Have you taken into account how the design choices you make today will impact the processes required in operations? How much time are you saving or costing the users of your product?
Training
Are you short-sighted in thinking that training your project staff or spending time learning how to get continually better is something you can’t afford?
Perhaps your customer doesn’t want to pay for training, because project staff should come to the project fully trained. Do they realize that technology does not stand still?
How much money and time will you waste a year from now because you saved a much smaller amount today by not valuing the concept of a learning organization, a learning project team? Have you ever heard the expression “penny wise and pound foolish?”
So, what steps do you take on your projects to include the whole product life cycle in decision making?
Muda is a Japanese word meaning waste; activity that does not add value.
Why would you do such a thing?
Why?
“There is nothing quite so useless, as doing with great efficiency, something that should not be done at all.” ? Peter F. Drucker
Shoveling Muda
For a long time now corporate offices have been intent on efficiency, on productivity. We have been shoveling value littered with muda, in some cases mostly muda.
We have been focused on getting better at shoveling. More efficient shoveling is the only way to get more done, right?
In our current mindset, yes. If you aren’t able to change the content of what you are shoveling, you are doomed to go on shoveling a mix of what’s valuable and a great deal of what’s not. We bring in machines to automate the shoveling to make it go faster. Sometimes this means even more muda seeps into the mix, but we’re moving more tons per hour so it must be good.
And then we use our fancy tractor shovel to dump the mixture of half value, half muda on to our customers.
We start with a pile of diamonds, but bring along some mud ourselves which we throw onto the pile of value. We tell ourselves the mud is necessary to keep the diamonds from moving around so much, or perhaps our supervisors require us to use mud. We see no useful purpose of the mud in this process, but we go along like good employees and do it the way it’s always been done. Many times the mud had a purpose once, but now we are mining something entirely different than when the mud was introduced originally. However the old timers have always used mud, so we keep using it too.
Eliminating Muda
What if there was a way to go about delivering what the customers wanted, without the mud? Or at least without bringing along our own mud to the project?
Well, there is. It’s called Lean Thinking.
You can start by asking Why. And then ask Why again, and again. I’m not talking about the 5-Whys technique, that’s a different topic.
I mean every time you or your teams partake in an activity of any kind, ask these questions:
Why are we doing this?
What’s the value of doing this?
Who gets value from doing this?
By the way, an answer like “upper management gets value because hey, they asked for it” is not good enough. Doing something just because somebody wants it isn’t good enough. Why do they want it? Are you sure they want it?
I’ve seen people produce reports by hand for years, and email it out to executives every day and then find out that no one ever, ever opened them. The reports were started at some time because a director asked for them. She probably used them for a week and got the information she needed, and then they became irrelevant.
But no one asked why. They just added it to the daily reporting deck, assuming it was valuable.
Well, it wasn’t. And as a result, some people’s entire jobs are almost entirely spent producing waste, when they could be producing value instead.
Think about the project(s) you are currently managing. What is their value to muda ratio?
The whole report is interesting but I want to focus on a particular question.
21. What is the greatest challenge of working with a distributed agile team?
“Poor Communication” was the biggest challenge by far. Go figure!
Now I’ll be the first to admit that co-located teams is an optimal situation if you can get it. There is nothing like face-to-face interaction between team members. At the same time, there are some strategies for dealing with distributed teams that I believe many teams are not taking advantage of.
There are two root causes cited in the study I want to discuss: cultural/language issues and tools issues.
Cross-Cultural Teams
I have experienced first-hand the frustration of assuming communication has been smooth with someone who does not have the same language as you for their first language, only to find out it wasn’t.
This is where I think several options are available to ensure understanding across the entire team. This isn’t really limited to cultural differences within a team, miscommunications and different interpretations happen all the time regardless.
Make It Objective
It’s important to make sure you are using some kind of documentation that makes it clear what is being delivered. Good software requirements work, user stories, use cases, behavior-driven development, etc.
Regardless of the project, I’ve seen requirements that can be interpreted 57 different ways, and those are not good requirements. If you had to have been there when they were written and be told what the intent was, they are not good requirements. Something I’ve started looking into heavily for my domain is behavior-driven development. It’s sort of like what I’ve known as test-driven development in the past, but much more user-focused. I like it. Aside from being very focused on the end user, it also makes it pretty darn clear what the functionality of the system is supposed to be. There is very little room for interpretation.
Make It Visual
The best way to communicate a concept clearly is through visuals, in my opinion.
This is why I love the kanban board. The whole team can see what’s going on at any given time. There are many online options available for distributed teams.
A picture is worth a thousand words, and it’s true. A diagram can convey a level of understanding that you just can’t get from words alone. Even when speaking to one another about parts and pieces of a system, our hands wave about wildly to illustrate specific points. At some point one of us usually says “Let’s go find a whiteboard, this is going to be much better if we can draw it.”
Well you can do the same with virtual teams too. Screen sharing and whiteboard tools are everywhere, free and paid. For my team members who are offsite, I love to use the desktop screen sharing application while on the phone with them. Either of us can convey understanding and have in-depth discussions this way as if we were in the same room.
Sometimes, the desktop sharing actually makes it seem better than being in the same room. You don’t have to lean over someone else’s shoulder or stare at a projector screen. You have the other person’s desktop right there in front of you.
Independent Validation
Having someone else on the team independently validate the work of other team members after development is finished is critical.
Why?
Not only for quality. No, this really helps teams gel in my experience. They get to know how their team members work better. They share tips and advice. They encourage each other. You know you’ve reached a good spot with independent validation as a part of your teams’ culture when people start actively seeking review from each other. That means they truly value each other’s opinions and communication is going to be enhanced as a result. It needs to be really easy to pick up the phone and just talk!
Tools For Distributed Teams
I think there is a lot of reliance on the wrong kind of tools out there for distributed teams. Task assignments shouldn’t be done through a software tool. In fact with something like kanban or some implementations of agile, it’s not even necessary. Self-organizing teams pull their own work out of the backlog.
Direct communication where possible is best, and so I really don’t believe in many of the tools out there today that get all whiz-bang about task assignments and capturing estimates in the tools, etc.
I’d rather have a simple kanban board, screen sharing software, a phone, and instant messaging. You can do time-boxed Agile just fine with a kanban board.
How do you think communication can be improved among distributed Agile teams?
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?
You can do this!
Earn your master's degree in project management without putting your life on hold at GoUWP.com! Apply today at GoUWP.comfor 100% online courses, 45 PDUs each. No entrance exam. University of Wisconsin- Platteville’s MS in Project Management is globally accredited by PMI. Combine academics and real-world scenarios for a 360-degree education.
If you have a distributed team, what are you trying to achieve with Agile approaches? Isn't Agile more for co-located teams? There are eight key benefits to working in a distributed Agile environment. A new report from ProjectsAtWork looks at each of those benefits – and how you can achieve them.
Most business and IT executives agree that any company able to rapidly deliver software of high and predictable quality with minimum budgets enjoys a significant advantage. However, practical experience shows that the challenges associated with software quality remain largely unsolved. Download the white paper Uplift Quality with Requirements Driven Testing to learn fundamental principles of Requirements Driven Testing.
Whenever you are asked if you can do a job, tell 'em, "Certainly, I can!" Then get busy and find out how to do it.
sponsors
Do you want to learn more about project management as a discipline and career?
Do you manage your projects with the perspective of the full life cycle of the product(s) you are creating?
We have been focused on getting better at shoveling. More efficient shoveling is the only way to get more done, right?
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.
If you've done any work in systems or software development, you've probably use Lines of Code (LOC) before.
