What Does Almost Done Really Mean? November 17, 2013Posted by Tim Rodgers in Communication, Project management.
Tags: communication, management, performance measures, project management
1 comment so far
About a year ago I earned a Project Management Professional certificate after learning the methodologies and structured processes formalized by the Project Management Institute. Almost all of my experience in project management has been in product development, and the PMP training provided a broader perspective on other types of projects. I was particularly intrigued and somewhat amused by the use of quantitative measures of project status based on Earned Value Management (EVM).
I can see why EVM would appeal to a lot of project managers and their sponsors and stakeholders. Everybody wants to know how the project is going and whether it’s on-track, both in terms of schedule and budget. They want a simple, unambiguous answer, without having to look at all the details. The EVM metrics provide project status and a projection of the future, in terms of the value and expenses of the project’s tasks that are already completed and still remaining.
The problem for many projects is that it requires a lot of planning and discipline to use EVM. Not only do you have to generate a full Gannt chart showing all tasks and dependencies, but you also have to estimate the cost and incremental value-added for each of those tasks. That’s going to be just a guess for projects with little historical reference or leverage. Quantitative metrics are generally less valuable when they’re based on a lot of qualitative assumptions, despite the appearance of analytical precision.
Whether or not you use EVM, everybody wants to express project status in terms of a percentage. “We’re about 90% done, just a little bit more to go, and we’re looking good to meet the deadline.” This kind of oversimplification often fails to recognize that the pace of progress in the past is not necessarily the pace of the future, especially when sub-projects and their deliverables are integrated together and tested against the requirements. There’s an old saying in software development that the last 10% of any software project takes 90% of the time, which is one of the reasons why agile development techniques have become popular.
While I applaud the attempts to quantify project status, I would assess a project in terms of tasks and deliverables actually either fully-completed or not, not “90% complete.” For large projects it’s useful to report deliverable completion status at checkpoint reviews where stakeholders can confirm that previously-agreed-upon milestone criteria have been met. This binary approach (done or not-done) may seem less quantitative, but it’s also less squishy. The overall status of the project is defined by the phase you’re currently in and the most-recent milestone completed, which means that all of those tasks leading up to the milestone have been completed.
That still leaves the problem of assessing the likelihood of future success: will the project finish on-time and on-budget? At some point you’re going to have to use your best judgment as a project manager, but instead of trying to distill your status to a single number isn’t it more useful to talk about the remaining tasks, risks, and alternatives? Sometimes more information really is better.
Why Can’t You Figure Out What I Want? July 29, 2013Posted by Tim Rodgers in Management & leadership, Organizational dynamics.
Tags: communication, leadership, management, manager, power
add a comment
Earlier this year I started working at a new company where, except for the brief job interviews, I was entirely unfamiliar and unknown to everyone. I’ve been through this many times in my career, changing jobs and relocating more often than most, I suspect. It takes a little while for your new co-workers and subordinates to figure out who you are, what you care about, and what you expect. Your style and preferences will not be immediately obvious, and it’s unlikely that others will be able to read your mind. You’re bound to have some miscommunication, misunderstandings, and missed deliverables until you get on the same wavelength, and until then you have to spend a lot of time explaining what you really want.
You can make this easier for everyone by being explicit, being consistent, and giving feedback.
It starts by determining your priorities as a manager. What are the key performance indicators (KPIs) for the team relative to the larger business? What does success look like? How will you measure the performance of each team member? The answers to those questions should enable you to figure out what decisions you need to make, what decisions require your input, and what decisions can be made by your subordinates independently. That will help your team understand what information you need and when you need it.
You can also help your team by consistently communicating strategic messages that are simple, unambiguous, and (ideally) quantifiable. Cost reduction, revenue growth, on-time production ramp, fewer defects, greater efficiency, and improved customer satisfaction are all examples of strategic messages that are easy to grasp, but if the priorities are always changing you can’t expect people to know what’s important on any given day.
Finally, each person on the team should have individual performance objectives that can guide their decisions and their choices about how they spend their day. The feedback and reinforcement you provide during your routine encounters should reinforce those objectives. You shouldn’t make it hard for folks to figure out what you expect from them.
How Much Information Should a Manager Give To Their Team? February 4, 2013Posted by Tim Rodgers in Management & leadership, Organizational dynamics, Project management.
Tags: communication, leadership, management, manager, power, project management
add a comment
I’ve been pretty busy over the last few weeks focusing on my job search, interviewing for a couple of positions, and preparing for a possible teaching assignment at a local university. The evaluation process at the university included a 15-minute audition that was intended to provide some insight to each candidate’s presentation and facilitation skills in a classroom environment. Fifteen minutes is not much time, and during my lesson planning I decided to deliver a small packet of information, repeated and reviewed. I know from experience that there’s a tendency to overestimate the ability of an audience to listen and absorb.
This reminded me of something I read during my preparation for the Project Management Professional (PMP) certification exam last year. One of the topics on the exam was Project Communications Management, which included identifying stakeholders, and planning the communication processes necessary to keep them informed, according to their expectations. Project managers were encouraged to strive for efficient communication, providing only the information that each stakeholder requires.
I suppose the intention is to keep it simple and avoid the confusion and doubt that can accompany information overload, but I don’t think this is necessarily a good strategy. There are potential problems when the project manager is the only person who has all the information about the project:
1. You run the risk of creating a dependency bottleneck, where one person must always be available to communicate status, resolve issues, and answer questions. This can be mitigated somewhat with easily-accessible project documents, assuming people know where to find them and are willing to use them.
2. Team members may be constrained by a narrow perspective that limits their ability to respond quickly or deal with ambiguity because they aren’t permitted to see the big picture. Surely the project benefits when the brainpower of all team members is fully-engaged. even at the risk of sharing “too much” information.
Look, I don’t think everyone needs to know everything all the time. I just think we shouldn’t be too quick to withhold information in the name of communication efficiency.
Professionals and Workers August 22, 2012Posted by Tim Rodgers in Management & leadership, Organizational dynamics.
Tags: career growth, communication, job satisfaction, management, power, retention, software quality
1 comment so far
I’ve been going through some old files now that I have some (unwelcome) time on my hands, and I found a Powerpoint presentation from 1997. I had just taken a new position, managing a software test team that was suffering from low morale. There was a widespread feeling that the work was unimportant and unappreciated by the rest of the organization. That could have been the beginning of a downward spiral, especially if higher-performers were able to find more rewarding jobs elsewhere.
I can’t remember where I first saw this contrast between those who are workers and those who are professionals, but it inspired the team and instilled a new sense of pride when I turned it into a presentation for an all-hands meeting:
|A worker:||A professional:|
|… is a robot, operated by a manager under remote control||… is an independent human being|
|… is focused on boss, activity, and task||… is focused on customer, result, and process|
|… performs tasks and follows instructions||… is responsible for performing work and assuring its successful completion|
|… is characterized by obedience and predictability||… is characterized by intelligence and autonomy|
|… is trained||… learns|
|… has a job||… has a career|
|… inhabits a precisely defined job and operates under close supervision||… is constrained by neither|
- A professional sees themselves as responsible to the customer. Solve the problem and create value. If the problem is not solved or value is not created, the professional has not done their job.
- Once provided with knowledge and a clear understanding of the goal, a professional can be expected to get there on their own.
- A professional must be a problem solver able to cope with unanticipated and unusual situations without running to management for guidance.
- Professionals ignore petty differences and distinctions within an organization. When we are all focused on results, the distinction between my work and your work becomes insignificant.
- A professional career does not concentrate on position and power, but on knowledge, capability, and influence.
- The professional’s career goal is to become a better professional and thereby reap the rewards of better performance.
The Teaching Manager August 1, 2012Posted by Tim Rodgers in Management & leadership.
Tags: career growth, communication, management, manager, training
add a comment
I think one of the most overlooked elements of a manager’s job description is the responsibility to teach. Managers should be measured on their ability to use the resources assigned to them, and anything a manager can do to improve the effectiveness and efficiency of their team is obviously a good thing for the business. Certainly all employees are expected to have acquired the minimum skills and training required to achieve their individual and team objectives. A manager coaches to their team on how to apply those skills and training in the unique ecosystem of the business, consistent with strategic priorities and complementary to the roles of internal partners, suppliers, and customers. This coaching is based in-part on the insights that come from the manager’s experience with success and failure — what works, and what doesn’t work– but managers should also recognize and promote best practices that are outside their personal experience.
Three other teaching opportunities for a manager:
1. Identifying skill gaps and recommending plans to close those gaps. The manager may have the knowledge and ability to provide training themselves, but what’s more important is the recognition of the gap and prioritizing the whatever training may be necessary.
2. Developing and encouraging good judgment so their team can act independently without the need for close supervision. This increases team productivity and enables the manager to spend more of their time on higher value-added activities.
3. Identifying and developing the next generation of leaders. As I wrote in an earlier post: “Those who actively participate in helping new leaders are valued employees who understand their role in helping the business continue and grow.”
Companies who invest in their human resources realize concrete and sometimes unexpected benefits. Managers at all levels in the organization are critical to that investment through their daily opportunity to teach.
Team Building Activities: Not For Everyone June 3, 2012Posted by Tim Rodgers in Communication, Management & leadership, Organizational dynamics.
Tags: communication, leadership, management, power, training
add a comment
I’m embarrassed to admit this, but I used to force people to engage in team building activities; specifically those structured exercises that are intended to teach something about working together more effectively. I originally joined in as a willing-but-skeptical participant when facilitators asked everyone to get out of our chairs and stand in a circle to throw a ball back and forth, or pair up with someone else who was blindfolded, or work with a team to figure out how to drop an egg off the top of the building without breaking it (the egg, not the building). It seemed to be something that progressive, forward-thinking managers were supposed to organize on behalf of their teams in order to uncover revelations and breakthrough thinking that would inspire teamwork, innovation, and productivity. That’s what I hoped for, but I see now that I was putting a lot of faith in a process that relies on accidental discoveries.
I’m sure these games must have worked for some teams otherwise surely the concept would have died early on. I don’t think I ever experienced a revelation when I was a participant, but I saw other people who seemingly got caught up in the excitement, or at least had something to say when the facilitator asked for “lessons learned.” At the time I concluded that I was trying too hard, and that I shouldn’t deny the teams I would later manage the opportunity to learn their own lessons just because I didn’t get it.
This may work for others, maybe as a way of getting people to think differently, but I know now that it’s not for me. It doesn’t fit my management style and I feel pretty silly doing it. I do want to inspire the team to work together collaboratively, to be innovative, and to develop their own ideas for higher productivity, but I’m not comfortable with using symbolic games that reveal hidden truths indirectly. I’d rather go directly to the team and tell them what we need instead of hoping to get there through a side door.
Keeping Specs Updated April 16, 2012Posted by Tim Rodgers in Communication, Process engineering, Product design, Project management, Quality.
Tags: change management, communication, management, process, project management, software development, software quality
add a comment
Some time ago I listened to the manager of a firmware development group explaining his team’s reluctance to keep requirements documents up-to-date for our product’s user interface. Basically he didn’t think it was worth the time, especially when the logical flow and the look of the UI were still moving targets. “Can’t we just do the coding first and update the specs later?”
I’ve written before about my love-hate relationship with process (see Process Conformance). I understand why people hate process. Often they think that it inhibits their creativity and makes them less flexible and agile. Generally, processes should be an enabler for greater efficiency and reliable execution, not a nuisance. When people follow the process there’s a lower cost for communication and alignment. Keeping requirements up-to-date sounds like a lot of extra work, but those documents are vital as a tool to make sure everyone understands the specs and aren’t working on an older version. The time it takes to update the specs should be balanced against the time and effort that would be wasted by not updating them or trying to communicate changes informally.
If the design team thinks they’re spending too much time updating specs, maybe they should be spending more time understanding why these changes are happening in the first place.
Long Distance Project Management March 29, 2012Posted by Tim Rodgers in Communication, International management, Management & leadership, Project management.
Tags: communication, leadership, management, process, product development, project management
add a comment
Today it’s unlikely that all the key members of a project team are co-located in the same time zone, much less in the same office. Managing a project is hard enough when you can walk over to someone’s desk to find out what’s going on, but it’s obviously a lot more difficult when the team spans geographies in addition to languages and cultures. (NB: I’ve also found that the likelihood of routine face-to-face communication falls off sharply when that person’s desk is more than about 50 meters away. At that point they might as well be on the other side of the world.) The communication delays and additional effort to reduce “frictional losses” due to misunderstandings can be especially taxing. Everything seems to take longer and it’s harder to prevent drift on objectives and priorities. What can be done to minimize the aggravation of remote project management?
1. As with any project, early planning is the key, specifically alignment about the project objectives and roles and responsibilities for all parties. I prefer in-person kick-off meetings with the remote team members to give plenty of time for discussion and questions, although for some that may not be practical due to travel costs or other restrictions. We certainly have the technology today to enable productive meetings without travel, but there’s a lost opportunity to build confidence during informal social encounters. I find that I have a stronger sense of obligation and personal commitment after I’ve shared a meal with someone, at least to have a face and a story to associate with the name. See more at: Managing Remote Teams.
2. I believe that remote teams have the best chance being successful when the project tasks are partitioned and allocated in a way that enables extended intervals of independent action, minimizes back-and-forth hand-offs, and allows them to focus on well-defined and measurable deliverables. This shouldn’t be difficult, assuming the remote teams already have specialized areas of responsibility, but it means designing a work breakdown structure that synchronizes the inputs and other resources those teams require, thereby reducing their daily dependencies.
3. That last point sounds like hands-off Management by Objective (MBO), but ironically remote teams need more — not less — attention from the project manager due to the increased probability of misunderstandings and drift. You can’t wait until formal reviews or phase checkpoints to find out how things are going, especially if the tasks assigned to the remote team are in the critical chain. I recommend regular phone conferences or “text conferences” (too much delay with e-mail exchanges that aren’t interactive) to check status, answer questions, and generally verify that everything is still on-track.
Slides: Not Just For Presentations Anymore March 26, 2012Posted by Tim Rodgers in Communication.
add a comment
When was the last time you wrote (or read) a multi-page report written using a word processing application? Microsoft’s PowerPoint and competing presentation apps seem to have become the new standard for all office communications that requires more detail than e-mail or text messages. Presentation apps apparently aren’t just for slide shows anymore. This trend has been the target of satire, see for example the viral version of Dr. Martin Luther King’s inspiring “I Have a Dream” speech rendered as sterilized bullet points (“I Have an Action Item”).
I suppose we could lament the demise of the written report. I belong to a generation that spent a lot of time learning how to compose a three-paragraph persuasive essay in less than an hour, with introduction, paragraph transitions, and a conclusion. I’d like to think this has helped me write better e-mails, and I’m sure that training will be an asset if I ever decide to write the next Great American Novel.
In business communication (unlike art), what matters ultimately is how effectively we transfer information from one-to-one or one-to-many, and I don’t think we should waste a lot of time criticizing the evolution of the medium. There are people who have already moved on from PowerPoint to animation and “voice and white board” videos that are very effective and entertaining. See for example Khan Academy lessons and the RSA Animate videos on YouTube.
Most of us lack the design or production skills to move beyond simple graphs, flow charts and fade-in/fade-out animation on PowerPoint, and unfortunately many are still stuck on bulleted text as the default slide layout. That’s not necessarily a problem when the slides are used to accompany an oral presentation with audience interaction, but flat, one-dimensional slides fail to convey useful information when they’re read later by people who weren’t at the meeting.
We don’t have to be artists, but can we at least avoid these examples of poor PowerPoint usage?
1. The “This is a Horse” slide. We’ve all seen something like this. The title of the slide is “This is a Horse,” and yes, that’s a picture of a horse. I can see that, but can you tell me why I should care? The title of a slide is like a story headline and should lead the viewer (or reader) to a shared understanding. “Trends in Worldwide Smart Phone Adoption” is not nearly as interesting a title as ” WW Sales of Smart Phones Now Exceed PCs.”
2. The “Here’s All the Data, You Try to Figure Out What It Means” slide. These are the slides with rows and columns of data, or perhaps a graph, but no explanation. The reader is left to draw their own conclusion, which may not necessarily be the conclusion that they’re supposed to draw. A critical reader will probably do that anyway, but at least tell us what your conclusion is. I assume you’re trying to communicate some finding, or possibly even persuade me to take some action. Please don’t make me guess. The easiest way to do this is to highlight the take-home message in a text box.
3. The “I Have No Idea What We Should Do Next, I Hope You Do” presentation. A longer version of #2 above, this is the presentation that ends abruptly with no next steps, no conclusions, and no recommendations. Even a report that provides a simple status update for an ongoing project should at least include a summary of near-term planned activities.
By the way, a simple bulleted list may be a terrible slide during the presentation, but it’s actually pretty effective for the person who reads the file later. I wonder if we should be creating one slide set for the meeting and another for those who couldn’t attend.
What’s Your Point? March 16, 2012Posted by Tim Rodgers in Management & leadership, Organizational dynamics.
Tags: communication, leadership, power
add a comment
American writer and humorist Fran Lebowitz said: “The opposite of talking isn’t listening. The opposite of talking is waiting.” In business we take turns talking and waiting, and occasionally listening. Talking, communicating verbally, is obviously necessary even in this era of email and instant messaging. But it’s not always clear why we’re talking in the first place. I often wonder about this, especially when I’m listening to someone extend a meeting. “What’s your point?”
I don’t want to over-analyze this, but I think it’s often worth taking a moment to consider the purpose of opening your mouth. Are you trying to add something constructive to the conversation? Correct someone who’s said something you disagree with? Show how much you know about this topic, thereby leaving a positive impression on the audience? Convince or persuade? Move the conversation in a different direction? Give a command? Teach? Or, just shoot the breeze?
Ultimately, shouldn’t our communications, not just our actions, add value?
On a related note, this made me laugh: http://holykaw.alltop.com/when-to-raise-your-hand-flowchart?tu2=1