pmStudent

I've been guilty in the past of transitioning from a technical lead role into project management and continuing to make technical decisions that should have been the responsibility of the new lead who replaced me.

I did this for about 6 months without even realizing it. People on the team were used to coming to me for advice and decisions on technical aspects of the projects, so they kept doing so even after the transition.

We all want to be helpful, so I continued to answer their questions and provide technical leadership.

I only directed people to the technical lead sporadically...if I was confident about my position on the matter, I just answered the question.

Signs of Trouble

Then I noticed my technical lead wasn't really doing all the things a technical lead should do...at first I thought perhaps they weren't 'stepping up' as much as they should to lead the team from a technical perspective.

Then I realized it was ME who was crippling their ability to be a leader on the project.

After that, when people would come to me for technical input, I would direct them to the lead to ask their advice. Rather than make decisions about implementation details, I would defer to them.

Let me tell you, the difference is tremendous.

A Technical Foundation Is Important

I still firmly believe that every effective project manager must have a foundation of knowledge and experience in the domain they are managing.

But when you empower your team (leads and all your team members) to take responsibility for most of the technical design and architecture, it makes everyone feel better about their job and frees you up to focus on strategic aspects of managing projects well.

Right and Wrong Approaches

Furthermore, you and your technical lead may have a different opinion about the "right" way to implement something.

Sometimes it's not a choice between "right" and "wrong" though, just two or more different possibilities that have their own pros and cons.

If you as the project manager take the decision making power away from your lead and team members, you risk undermining them for no good reason.

Even if you prefer option A, it's likely that option B is just as good.

I'd rather let the team choose their own path as much as possible and only intervene when I have compelling reasons to believe one approach is far superior to the other.

Get Strategic - It's Your Job

Sometimes as the project manager you can spot dependencies and additional risks that one approach will create that your team members don't see.

Things like code maintenance and other product life cycle considerations may not be at the forefront of your team member's minds as they do their day-to-day work, but as the project manager that is part of your responsibility.

Empowering Leadership From Your Team Members

Even in that case, whenever possible I like to educate the team about the risks I see and let them still make their own decision after getting all the facts.

People who are actively involved with making decisions about the work they do have higher job satisfaction, are more productive, and a pleasure to work with.

Share your experiences and thoughts in the comments.

Technical Project Managers - Get Out Of The Way! <-- Click to Tweet This

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?