pmStudent

Saw this post recently in Project Management Central:

Hello All, I'm a professional from telecommunication industry. Currently I'm employed with a telecom giant. My current profile makes me work for technical support group, however, I'm willing to move my career ahead in project management. But since I have no previous project management experience I cannot go for PMP certification. However, I can pursue Prince2 ( foundation + practioner) as it doesn't require any pre-requisites to be met. And I hope that Prince2 will aid me to change my job profile to project coordinator/ assistant. I'm also pursuing MBA in project management from Disance education. Please advise me if Prince2 is worth doing for me!

I get questions like this one a lot. People trying to decide between an APM, IPMA, PMI, or PRINCE2 certification. Believe it or not my answer to this question is always the same.

It depends. :-P

Seriously dude. Let me explain.

Target Organizations

Organizations are as different as anything else in our world. They all have different cultures, needs, and backgrounds. Some of them may absolutely HATE the PRINCE2 certification. Perhaps the founder had a bad experience, maybe the culture has no respect for these industry certifications. Whatever.

Some may have drank the kool-aide of a particular certification and have based all of their processes around that particular framework and/or methodology.

You Need To Find Out

Do some research and find 3-5 organizations you want to go work for. For most of you that will be local you where you are currently living, for others who don’t mind moving you can expand your search.

There are many things you can look for as sign posts of a culture you’ll enjoy and be able to grow with. But it starts with your own goals.

If you want to be in a free-wheeling environment that is unstructured where you can make many changes and have a lot of influence even as someone new to the company, try a start-up.

If you want to land in an environment filled with mentors and established career paths in project management, try a larger established company who has these things in place.

Network Like A Maniac

Networking is a process, not an event. You should always be engaged in networking, not just when you are looking for a job. That’s actually the worst thing you could do, only network when you are hungry for a job. You are going to turn off a lot of people that way.

Networking is an ongoing process of building relationships and trust over time with people who you like and who like you. You share common interests. In the case of targeting organizations, you may share the interest of a particular company. Perhaps they work for that organization already.

The strategies and tactics involved with good networking are too exhaustive to cover in a blog post. If you want to go deeper into the rabbit hole with me, you can.

I can tell you the primary approach however.

Be Helpful, Add Value For Other People

Me! Me! Me!

This is the wrong approach. When you reach out to people only to ask them if they know of a job, you are going to turn them off. It doesn’t work unless you’ve built a relationship and trust over time.

Instead, do your best to help them. Ask them insightful questions about the work they do. Don’t just ask what you can do to help them, get to know them well enough that you can come up with an idea of how to help them and make it so all they have to do is say yes.

Oh yeah, and you can ask them if their company gives a rip about certifications somewhere in there.

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?

Waste.

There is almost nothing I despise more.

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.

Self-Induced Muda

Now what if I tell you the muda involved in the above scenario is mostly self-induced? We’re actually creating the muda ourselves in many different ways.

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?

Projects At Work just released a new report called “Distributed Agile Teams”.

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?