On this theme of Conventional Wisdom…. Not too long ago I was hearing lots of things about Agile.  Most of it was coming from my software development colleagues, but also from project managers in other disciplines.  There seemed to be a significant amount of intellectual intensity (which I interpret as emotion, but would not get that admission from the participants — we’re a very rational bunch).

At that time, there seemed to be two major camps:  the “new lighters” and the “protectors.”  The new lighters had seen the truth and seemed to feel a mixture of disdain and pity for those of us not yet onboard.  The protectors seemed to feel it was almost a duty to point out the failures of Agile and to prevent the chaos (which is evil) from coming into our midst.

If this sounds too simplistic and melodramatic, I won’t disagree.  And yet… a lot of the tone of the “arguments” did strike me as more than mildly like a kind of religious war.  Some of the words in the debate struck me as boiling down to “heretic,” “blasphemer,” “zealot,” “luddites,” “inquisitors,” and (horrors!) “old-fashioned.”

Of course, much of the public displays are made by those with the strongest sense of mission — most of us were not directly involved in the war.  Yet, one of the unfortunate outcomes of that conflict was, in my mind,  the notion of the Agile versus the PMBOK.  I would like to point out that the title is: “A Guide to the Project Management Body of Knowledge”  — it is not THE guide.   For the new lighters to say that PMIers are blind and misguided, the “proof” being that Agile ideas are not explicitly stated in the Guide was , to me,  just as unjustified as the for protectors to say that since Agile ideas aren’t in the “book” they should not be part of what we do.

What I see today is quite different.  There are still some doctrinal debates going on, but I see a more integrated approach.  I hear a lot more statements like, “We’ve been doing these things that are not in the Guide for years… we just never called it Agile before.”   To be sure, not all of these statements are backed up in fact.  It doesn’t mean that Agile ideas have usurped the “traditional” PM tools and ideas.  I believe that it does indicate that the new lighters and the protectors have both failed and succeeded.  The new lighters have succeeded in that the ideas of creating customer value early and often are being baked into more projects.  The new lighters really haven’t succeeded in completely overturning the old order, which is a win for the protectors.  Yet, the protectors have also failed because agile ideas have breached the walls, and for many of us our projects will never be the same as before.

Richard Wysocki’s book: “Effective Project Management: Traditional, Agile, Extreme” (ISBN: 978-0470423677) looks at projects as needing a spectrum of approaches.  One of our founding bloggers here, Kimberly Wiefling, gives us very real-world (and non-dogmatic) ideas in: “Scrappy Project Management: The 12 Predictable and Avoidable Pitfalls Every Project Faces” (ISBN: 978-1600050510) (although, I do find it fascinating that there are 12 pitfalls – a deeply mystical number!).

While some of the debate seems in retrospect to have been a lot of posturing, perhaps it was inevitable and even desirable to have a somewhat religious fervor — these are important ideas that can cut into some deeply held ideas that,  when re-examined, will yield valuable fruit.

We’ll look at some specific ideas that go beyond the Guide (or, at least are between the lines).

(note: apologies for the mixed metaphors – some intentional, some probably not)

Technorati Tags: best-practices, change, common-sense, communication, continuous-improvement, project-management, project-manager-role

I have been lucky enough to witness (and in some cases be a part of) several overturns of conventional wisdom.  I remember hearing how quality “costs money” and “we can’t afford higher quality.”  Now, it’s common to think about quality and value perception strategically.

I remember working with factory schedulers where they were driven by measures, such as utilization % and unit cost allocations, to build massive amounts of inventory (some of the consequences of which were quality problems!).  Now, it’s common to use Just-In-Time and Theory of Constraints concepts in production planning.

Our US auto industry is emblematic for this movement.  In the early and mid ‘80s I was working with several automotive companies.  At this point, the domestic industry still had a dominant market share (in the US), but companies such as Toyota, Nissan, and Honda had made significant gains in share.  Remarkably, those Japanese firms weren’t all that secretive in what they were doing.  Yet, I saw opportunities to apply these techniques (many of which did not have Japanese origins) repeatedly be ignored by US firms.   Now, many of the “heresies” of the past are integrated into the standard practice.

What could account for this strategic myopia?  Lots of factors — perhaps years of being big and successful.   On the other hand, these people were NOT stupid (of course, there are always exceptions — on all sides).  Many of the talented were among the most adamant against the new ideas.   I wish I could say that I was very talented AND saw the new “light.”  In fact, I was too naive and untrained.  For me, the “new” did not have to displace the “old.”

“In the beginner’s mind there are endless possibilities, in the expert’s there are few.”
– Shunryu Suzuki – Zen master

As a consultant and project manager I’ve come to realize that the value my clients and teams receive is often due less to knowing things (but please don’t tell them), and more to being able to “see” new things — and a need to ask questions.

Over the next week, let’s explore some of the ways we, as project leaders, are are encountering conventional wisdom that need overturning (or at least some improved interpretation!) and how we do it.

Cheers!

Technorati Tags: change, common-sense, real-world

Not an engaged team member

As project managers, it’s tempting to focus entirely on our project plan.  But successful execution of your project plan is entirely dependent on your project team.  And your project team is dependent on each team member!  For example, if your team is all working well together except one person, who is lacking motivation and missing deadlines, than the whole team will start having trouble, and your project success may be in jeopardy.

• Really get to know each member of your group: figure out their strengths and weaknesses, their needs, and any special skills they can bring to the group.
• Work out plans with each team member on how they can accomplish their individual goals while delivering on the project objectives. Find out what’s important to them – what gets them excited about their work.
• For each person, find out how independent and experienced they are. Make sure that they have the right level of competence for how you plan to manage the project. If you will be giving each team member lots of latitude in how they solve problems in their area, do they have the experience and emotional intelligence to handle that responsibility well?
• Don’t forget to praise and reward each individual for her contribution to the overall team and the success of the project.
• Help define each person’s role within the group, and agree on the tasks they’re responsible for.
• If any project team members seem to be lagging behind, coach them until they’re back on track.
• Is each project team member committed to the delivery dates?

It’s easy to forget that project managers are more managers of people than they are managers of technology. If you manage the people correctly, the people will manage the technology.

You need to manage your individual team members effectively in order to prevent burnout. In some environments, the customer will always be there with new demands, new “Priority Ones” that require you to drop everything and fix now.

It’s your job to manage these demands. Not to just acquiesce and keep pushing your team members, but to present trade-offs to the customer. Showing the value of the current path, demonstrating the impact the change will have, and helping them make a more informed decision. The result is a more engaged customer, who gains more satisfaction from feeling more in control of the output. At the same time, your team members are more engaged.

It used to be that project managers believed that you needed to crack the whip over your team members, that if you gave them any leeway they’d slack off and surf their favorite sports websites.  However, now we know better. Being focused and excited by your work comes naturally to most people.  Creativity is widely distributed on your project team.  People want to be proud of their work.  People will seek responsibility, if you let them.  If you think your team is mediocre, and needs your leadership to be successful, trust me, they will rise to the occasion and give you mediocre work.  If you want your folks to surprise you with amazing work, you need to engage them.

The best way to motivate team members is to respect them, give them autonomy, and help tie them to a strong purpose.  When you let your team members figure out how to solve a problem, and how to work together, it can have a powerful effect on individual performance and attitude.  Autonomy leads to higher productivity, less burnout, and more enjoyment of work.  Make an effort to see issues from your team member’s point of view.  You provide the problem, and listen to find the answer.  Let your team figure out the best solution.

Involve people in goal setting. Employees have greater commitment to goals they helped create. Individuals are more engaged when they’re pursuing goals they helped create. If you create a goal for someone, it will be less aggressive than the goal he chooses for himself, as people like to stretch themselves and do work they can be proud of. They will do everything they can to meet this goal.

Autonomy creates motivated, happy employees.  If you need folks to be creative and problem solving, why not get into the habit of engaging them on that level in the workplace?

Pushing back on team members

Your team members get a bit wiggy in giving you an accurate estimate for a lot of reasons.  Maybe they have no idea how long the task will take, or maybe they’re afraid they’ll get pulled away to fix the CEO’s email account for the third time that week.

You can help your team members feel confident in giving you accurate commitments by asking for a range of dates for delivery.

A range of estimates doesn’t mean you adopt the latest date, just to be on the safe side.  Parkinson’s Law says, “Work expands so as to fill the time available for its completion.”  If you give most of us more time than we need to do a task, we will often use that extra time to make the task “better,” by adding features, doing additional testing, etc.  While obviously good intentioned, this kind of “gold plating” will make the project take longer than it should, and may introduce new issues and risks.

The best way to get a range of estimates for a task: Instead of asking Joyce when her task will be completed, as her for a best-case scenario, worst-case scenario, and most likely scenario.  Discussing the rationale behind her numbers will bring up risks and issues. Also, now that Joyce feels like she doesn’t have to deliver it at the first opportunity, or to be safe and pick the last possible date, she will feel more confident committing to a reasonable date, which she has 90% confidence of achieving.

In order to get a good range of dates, allow each team member enough time to think through the problem before getting a commitment.  If you ask a team member to estimate a task on the spot, he will probably make up a number quickly just to make you go away.  Giving folks the time to come up with a careful estimate will pay off in greater accuracy in delivery.

You can also get around padded estimates by asking for task effort, instead of duration.  Let me explain.

If you ask your team members, “When can you get this task done?” their answer will vary, as they calculate other projects they might be working on, other issues that might come up.  Instead, consider asking, “Ok, pretend you can work uninterrupted, nonstop on this task, with all the caffeine you can drink. What’s the number of hours you need to get it done?”  Once you know the amount of effort required, it allows you to add in all the variables to come to a real duration.  Your team member shouldn’t have to do that calculation on his own. Be sure that the estimate you develop together takes into account the skill level of the folks doing the work. Just because it might take a normal person 3 days to complete this task, doesn’t mean that it will take Alice three days.  It might take her one afternoon, because she has specialized skill, or it might take her a week, because she needs to come up to speed on some underlying concepts before she can really get going.

No one works 100% of the time.  By acknowledging this in our estimation process, we can get to more accurate duration estimates.

By explicitly examining and working through all the buffers needed, you get the information you need to estimate as accurately as you can during planning. The more uncertainty, the greater the buffer.  You can have contingency amounts for a particularly risky work package, or for the project as a whole.

The size of the contingency, and whether it is at the work package or project level, is entirely dependent on the risk inherent in the project at the time the schedule is developed. So you see, padding isn’t always bad – just as long as YOU’RE the one doing the padding!

Help your team start each of their tasks as soon as possible in the schedule, as this will also reduce risk and uncertainty.

And above all, make sure that some externally mandated date doesn’t drive the thought process for your team members! You need to understand what it really takes to deliver on tasks, not drive your people to a death march. This can be tough, as some of your shareholders may assume that everyone pads their estimates, so they may want you to cut the commitments you’ve made. This is not a game you want to start playing! Be ready to carefully defend your schedule if challenged.

If estimates for some tasks are still fuzzy, it might be a sign that you need to break that task down into lower level tasks, in order to get to a clearer estimate.  If your work breakdown structure is flawed, your estimates will be inaccurate, so it might be a good time to make sure you don’t need to refine things a bit.

Technorati Tags: estimation, padding, scheduling

You need to come up with an accurate schedule for your project – well, as accurate as you can – but you suspect your team members are adding extra time to their estimates.

How can you overcome this and get to a realistic, reliable schedule?

If a little padding is added to this task, and a little is added to that task, pretty soon it adds up to a real significant change to the schedule!

A little padding's not that scary....

The problem with padded estimates is they are not treated as a contingency.  Fred thinks he can do his task in 3 days, so he tells me it will take him 5 days.  Instead of starting his task on Monday, he starts it on Wednesday, since he has extra time.  Then once Friday comes, he realizes that there are other conflicts, and he’s unable to deliver on time.

Estimates are only as good as the estimator is at predicting the future, and most of us aren’t working as psychics on the side.  The situation is even worse with junior employees, who have less experience in estimating.  If her estimates come up short, she will be penalized.  If her estimates are padded, she may be found out, her manager may think she’s dishonest, and management will cut all her estimates in the future. This can lead to an ugly arms race, where she pads her estimates more, and management cuts her estimates, completely breaking down the planning process.

If your schedule turns out to be wildly inaccurate, that will cause others to question your estimates in the future, and you’ll find your budget and schedule cut.

So how do you get to a real, trustable estimate?

First of all, build consensus on project estimates with the whole team.

Team members build padding into their estimates in order to feel confident in their ability to be successful.  Most folks don’t think this is bad; it’s just a form of contingency planning.

Your team member may be thinking, “How long will it take?  I have no idea!  I’ll take my best guess and double it!”

If you have worked with your project team for a while, you’ll get a feel for how each individual modifies his estimate, and can tweak it accordingly in order to get an accurate result. I know that everything Jerry gives me, I need to add 50%, because he’s an aggressive estimator, while I know that I should reduce 20% from anything Floyd tells me, because his estimates are overly conservative.

But if you have a brand new team, who you haven’t worked with before, you don’t have that knowledge. You don’t know how to modify each estimate in order to get to an accurate schedule.

You can avoid the problem of chronically padded estimates by having the team reach a consensus on their estimates in an open meeting, where team members would be less likely to pad their numbers. In that meeting, team members can go over assumptions and risks, and feel much more confident in the numbers they’re providing. This way, you can be sure that the project requirements are clearly understood by the folks doing the estimating. A well-informed team will always produce better estimates!

If possible, arrange for another person to facilitate this meeting, as you will be needed as a participant.  You may have a perspective that some of your team members do not about project priorities, constraints and assumptions, and you need to be part of the decision making process.

In this case, more experienced estimators on the team can help figure out where an estimate provided by others might be inadequate, and adjustments can be made at that time.

Instead of blindly increasing padding on schedules, use your risk management skills to determine where risk is greatest, and determine appropriate strategies.  When you create a good risk plan, you’re reducing uncertainty, whereas padding your numbers only increases uncertainty. If your project is new and unique, that will make the process of getting good estimates more difficult, and that issue is best resolved using the risk management tools you already know and love.

Also, if your project team members know that some overall contingency is built into the schedule, rather than on each individual task, they will feel less of a need to pad their dates.  Make sure to communicate to your team about project level buffers, so everyone understands and is on the same page.

Tomorrow I’ll add some more ideas of what to do about padded estimates from your team members. Is this a problem on your projects?  If so, how do you deal with them?  Let me know!

Technorati Tags: estimates, padding, scheduling

For years I’ve been using a rubber chicken in my consulting work to burn into people’s consciousness the concepts of personal accountability and a belief in an internal locus of control. Holding the chicken at shoulder height, I release it and ask why the chicken fell to the floor. Victims blame gravity. (Some people even blame the chicken!) Leaders say “Because you released it, Kimberly.” It’s a simple message, but an important one for leaders. No matter how tempting it may be, if we blame circumstances for our problems we give away our own power.

To reinforce this message I carry a bunch of tiny rubber chickens with me to give to people as a keepsake. I’ve met people years later who still have that chicken. It’s a quirky reminder of an essential leadership mindset – that, regardless of circumstance, we must focus on holding on to the chicken. Or something like that.

I have been carrying that rubber chicken everywhere for quite some time now, but recently the rubber chicken has taken on a life of it’s own. For the past 5 years I’ve been working in Japan for a week or two almost every month. My Japanese colleagues have shown an inscrutable love of the rubber chicken. My agent in Japan, ALC Education’s Global Management Consulting Group, insisted that the chicken be featured in an ad that they placed in the biggest business newspaper in the country, and the chicken has a permanent place on their website. Go figure.

Sometimes we have a very serious message to convey, but that doesn’t mean it has to be communicated in a totally serious way. There’s plenty of research to suggest that people remember the unusual. If you want people to remember the key points critical to the success of your project you might want to find the equivalent of a rubber chicken, and include it in your communication. Naturally some people think it’s frivolous or silly to resort to such tactics. But, for me, the effectiveness of communication is judged by the impact it has on project results, not whether it would win the approval of every other human on earth. I’m concerned with what works.  The chicken works.

Of course it hasn’t been easy traveling all over the world with that darn chicken. He was banned from entering Steve Martin’s banjo concert at the Mountain Winery in Los Gatos, and was mistakenly identified by a small child as a critical element in the “treasure hunt” on the back of the kid’s menu at Buck’s Restaurant in Woodside. (Yes, I was accosted by a small child for carrying that chicken!)

What could you do to make an important part of your message memorable? Take a risk! Being effective and successful is way more satisfying than winning the approval of the entire human race.

Technorati Tags: Accountability, Global leadership, global management, locus of control, rubber chicken

I’m delighted to post this story on behalf of Emily, who sent it to me as evidence that she was becoming more scrappy. In this story Emily shows us how we can help our teams think things through and clarify goals by asking good questions and facilitating discussions that people are “too busy” to have without our influence. It can take courage to schedule a meeting when people feel they have “real work” to do. But – done right – meetings ARE real work. Read and learn from Emily’s courageous leadership! – Kimberly Wiefling, Author, Scrappy Project Management

GUEST POST by  Emily Hennessee, Business Analyst & Project Coordinator, LightSpeed Technology

One of the bad habits I’ve developed that stems, I believe, from not having any formal technical training, and yet being responsible for managing software development projects, is that I sometimes tend to not ask enough questions to my team. In particular, I tend not to ask questions about exactly how they envision changes will look below the surface, or user interface, during the planning phase of our major projects.  I almost always have a very clear picture of the high level product, and I’m able to draw diagrams of what it needs to end up looking like to the user.  But when they hear the requirements and say, “Okay, all we need to do is A, B, and C.”, and all A, B, and C are all foreign languages to me (or maybe they are familiar but I can’t visualize the mechanics of it) I sometimes assume that they know what they’re talking about, and I’m the only one who doesn’t get it. So I don’t ask. They’re doing the work, so I figure that as long as they “get” it, we’re good.  Now I will say I’m not ALWAYS that bad, but even occasionally is too often.

Part of what causes this is time constraints, but I’ve learned that this is no excuse in a scrappy project world.  So yesterday I organized a call to discuss a project to implement an error checking and notification system on 3 of our major processes.  It was a particularly complex discussion around writing events to an SQL table and determining the base units of items we were going to measure for each process.  Needless to say I hit a few technical road blocks in my understanding during the discussions, but I’m proud to say that I put my foot down and demanded plain English answers. The call lasted a total of 3 hours, because the more I asked, the more ideas started to pop into my team members heads about alternatives and additional features.  The good news is that we all walked away with a very thorough understanding of how we wanted this system to work and look.  The bad news is, we’re not sure right now if we have the resources and time to make the ideal set of changes (to redo a much larger process as part of this effort).  BUT . . . at least we’re not diving in head first into a project with false expectations and unclear requirements, which is something we do far too often around here.

So, a small victory for me!

Emily Hennessee

Business Analyst & Project Coordinator

LightSpeed Technology Group

Technorati Tags: courage to hold the meetings required to do the job right, facilitating team discussion, giving your team time to think, Leading technology you don't understand