pmStudent

I'm going to make a very specific case today.

Let's review the Theory X / Theory Y models of McGregor, knowing full well they are just models. There is no purely Theory X or Theory Y manager.

Theory X

Assumes project team members:

• are lazy by default
• will avoid work if they can
• inherently dislike work
• will show little ambition without an enticing incentive program
• will avoid responsibility whenever they can

Assumes project team members need:

• to be told what to do, given structure
• to be closely supervised
• comprehensive systems of controls developed
• respond best to threat and coercion (carrot and stick)

Results in:

• blaming people before systems and processes
• culture of CYA (cover your a$$)
• hierarchical structure
• focus on compliance
• top-down decision making

Theory Y

Assumes project team members:

• find satisfaction in doing a good job
• enjoy challenging and meaningful work
• are self-motivated and responsible
• are creative problem solvers

Assumes project team members need:

• to be able to learn new skills
• to accept responsibility on a regular basis
• to exercise self-control and self-direction

Results in:

• evaluating systems for flaws before people
• flat organizational structure
• climate of empowerment and trust
• culture where mistakes are opportunities to learn
• focus on commitment
• shared decision making

Knowledge Work, Specifically Software Project Management

My verdict is that software project managers exist out there in numbers who are heavily geared towards the Theory X side of things. And that the more they are, the more their teams succeed in spite of them rather than because of them. And even when they do succeed, it's far below the potential of the team.

Now, what's your verdict?

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?