How Much Information Should a Manager Give To Their Team? February 4, 2013
Posted 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.
Decisions Based on Psuedo-Quantitative Processes December 28, 2012
Posted by Tim Rodgers in Management & leadership, Organizational dynamics, Process engineering, Quality, strategy.Tags: leadership, management, performance measures, problem resolution, project management, six-sigma, strategy
add a comment
I’ve spent a lot of time working with engineers and managers who used to be engineers, people who generally apply objective analysis and logical reasoning. When faced with a decision these folks will look for ways to simplify the problem by applying a process that quantitatively compares the possible options. The “right” answer is the one that yields the highest (or lowest) value for the appropriate performance measure.
That makes sense in many situations, assuming that improvement of the performance measure is consistent with business strategy. You can’t argue with the numbers, right? Well, maybe we should. In our rush to reduce a decision to a quantitative comparison we may overlook the process used to create those numbers. Is it really as objective as it seems?
There’s a common process for decision making that goes by several different names. Some people call it a Pugh diagram or a prioritization matrix. A more sophisticated version called a Kepner Tragoe decision model includes an analysis of possible adverse effects.
These all follow a similar sequence of steps. The options are listed as rows in a table. The assessment criteria are listed as columns, and each criterion is given a weighting factor based on its relative importance. Each row option is evaluated on how well it meets each column criterion (for example, using a scale from 1 to 5), and this assigned value is multiplied by the weighting factor for the column criterion. Finally, the “weighted fitness” values are summed for each row option, and the option with the highest overall score is the winner.
At the end there’s a numerical ranking of the options, and one will appear to be the best choice, but the process is inherently subjective because of the evaluation criteria, the weighting factors, and the “how well it meets the criteria” assessment. It’s really not that hard to game the system and skew the output to provide any desired ranking of the options.
I’m not saying this is a bad process or that the result is automatically invalid. What I am saying is that this isn’t like weighing two bags of apples. The value of a decision analysis process isn’t just the final ranking, it’s the discussion and disagreements between the evaluators, which are obviously subjective. We shouldn’t consider the process to be an infallible oracle that delivers an indisputable answer just because there’s math involved.
I’m sure there are other examples of psuedo-quantitative processes that shouldn’t be accepted at face value. Leaders should question assumptions, listen to dissenting opinions, and check for biases. It’s rarely as cut-and-dried as it seems.
The Power of Three (Defect Categories) December 5, 2012
Posted by Tim Rodgers in Project management, Quality.Tags: factory quality, project management, quality engineering, software quality, test & inspection
add a comment
Over the last few weeks of software projects at HP we would have cross-functional discussions about open defects to essentially decide whether or not to fix them. We considered the probability or frequency of the defect’s occurrence, and the severity or impact of the defect to the end-user, then assigned the defect to a category that was supposed to ensure that the remaining time on the project was spent addressing the most important outstanding issues.
I don’t remember exactly how many different categories we had in those days (at least five), but for some reason we spent hours struggling with the “correct” classification for each defect. I do recall a lot of hair-splitting over the distinction between “critical,” “very high,” and “high” which seemed very important at the time. Regardless, everyone wanted their favorites in a high-priority category to make it more likely that they would get fixed.
I think we could have saved a lot of time if we had used just three categories: (1) must fix, (2) might fix, and (3) won’t fix. That covers it. Nothing else is necessary. The first group are those defects you must fix before release. The second group are the ones that you’ll address if you have time after you run out of the must-fix defects. The third group are the ones you aren’t going to fix regardless of how much time you have. To be fair, the might-fix defects should be ranked in some order of priority, but at that point you’ve already addressed the must-fix defects and it won’t matter much which defects you choose.
I’m not a psychologist, but I think there’s a big difference between trying to classify things into three categories vs. trying to classify things into more than three categories. I think the human brain gets a little overwhelmed by too many choices. Two might seem better than three because it forces a binary selection, but I think it’s a good idea to compromise and allow for a “maybe” category rather than endure endless indecision.
Predicting Future Success for a Project Manager November 20, 2012
Posted by Tim Rodgers in job search, Management & leadership, Project management.Tags: hiring, job search, management, project management
add a comment
If you were interviewing people for a project manager job, what criteria would you use to make the decision? What results or characteristics differentiate an above-average project managers from the rest? Today it’s relatively easy to become a certified Project Management Professional (PMP), and that may be a reasonable minimum requirement for many positions, but you would surely also want to hear something about the candidate’s recent achievements.
“Successfully completed the project” doesn’t tell you much since a project may fail or be abandoned for reasons that have nothing to do with the project manager’s performance. Only slightly better is a statement that the project was completed “on-time and under budget.” That sounds good, but it’s easy to claim and usually impossible to verify.
So, what exactly does a project manager do, and how can we tell if they’ve done a good job? Can we isolate the performance of the PM from the rest of the team? What information can we use to assess the probability of the PM’s success in the future?
I think it may be impossible to isolate and quantitatively measure the performance of a PM, primarily because of the many unforeseen and uncontrollable factors that can lead to schedule variances, budget variances, and other high-level measures of a project. Certainly a closely-monitored project with effective risk management and contingency planning may be less susceptible to these factors. However, unless the PM is guilty of failing to incorporate key inputs to the project plan, or failing to plan altogether, it’s not necessarily the fault of the PM if the project doesn’t meet its objectives.
The basic process of project management is pretty straightforward. Any assessment of a PM should include how well they respond to things that are not part of the standard process or the original plan. Can they cite examples of adaptability and creativity when managing the inevitable changes that happen in any project?
The length of the project, the number and variety of stakeholders, and the degree of leverage from previous projects can provide an indication of the project complexity this PM has handled in the past, and what they will be more likely to manage successfully in the future.
I also believe that past failure is better predictor than past success, specifically what the PM has learned from past failures. Certainly I would want to hear about the candidate’s experiences in overcoming obstacles and solving problems, but I also want to know what they learned about avoiding those obstacles and problems in their next project.
Those are three indicators of future success for a PM: adaptability, familiarity with complex projects, and a commitment to learning and continuous improvement based on experience.
Starting a Product Development Team November 12, 2012
Posted by Tim Rodgers in Management & leadership, Product design, Project management, Quality.Tags: 30-60-90 day plans, early stage companies, management, organizational models, outsourcing, product development, project management
add a comment
A few weeks ago I interviewed for a job with a local company that decided they wanted to bring product development in-house and transition out of a contract engineering partnership. I didn’t get the job, but that experience got me thinking about how I would create a product development team from scratch, specifically how to organize the team and what skills are required.
In this case the firm had an established product line with suppliers and a contract manufacturing partner, so the general “make vs. buy” decisions had already been made. Regardless of the status quo, it’s a good idea to review those decisions from the standpoint of the firm’s expected source of competitive advantage. In other words, how does the firm plan to differentiate itself in the market? What are the critical-to-function or critical-to-performance characteristics of its products? Can these be reliably sourced from external suppliers today, and can those suppliers keep up with the anticipated trends in technology to maintain that advantage? If not, then those design elements and product characteristics should be developed internally.
In order to keep the internal staff at a small and manageable size, this suggests three distinct (but possibly overlapping) functions within the product development team:
1. Specialized engineering with domain expertise in the critical design functions that must be developed in-house. These are the people who have deep technical understanding and design experience with the key parts and sub-assemblies. The skills needed here are engineering expertise in the target areas of differentiation.
2. System-level design architects and product integration engineering. These are the people with responsibility for high-level product design and system integration issues. This could include overall project management for the entire product development effort.
3. External supplier and partner management. This isn’t necessarily the same thing as traditional supply chain management because it requires technical oversight to the designs and other deliveries from the suppliers. The skills needed here include remote management and communication.
Two other considerations are the lead time for any invention or innovation required for new products (possibly leading to a dedicated concept or research team); and the expectations for ongoing support or upgrades for products already sold (possibly leading to a dedicated sustaining engineering team).
My inclination is to avoid separate teams for these purposes, unless the expected volume of work in either area is significant. Without morale-boosting attention from management, sustaining engineering teams tend to suffer from an inferiority complex, working within design constraints and fixing problems created by others. I’d rather assign product maintenance to the same team that designed the product, which also avoids the need for knowledge transfer. Similarly, a dedicated research team that doesn’t have ultimate responsibility for product development may underestimate sourcing limitations, integration issues, and production ramp snags. In order to have value, technology must be successfully implemented within cost, schedule, and quality margins, and not just thrown over the wall to a development team.
That’s the framework that I would use to build a new product development team, or analyze an existing team for skill gaps. The next step would be to perform a process and development lifecycle assessment, but that might better addressed in a future blog post. At minimum there should be separate phases for product design, factory prototyping, and production ramp, with phase gate review meetings and quantitative go/no-go criteria. I’ve written about lifecycle considerations in earlier posts (see for example Ramp Readiness Indicators for Product Development). Of course standard project management processes such as early stakeholder alignment, issue tracking, change management, and end-of-project reviews should also be in-place.
Stakeholders Change Their Minds: Get Used To It November 8, 2012
Posted by Tim Rodgers in Management & leadership, Product design, Project management.Tags: change management, management, product development, project management, quality engineering
add a comment
Here’s what we’ve been taught: spend the first part of your project talking to stakeholders and customers, develop a deep understanding of their expectations, translate those expectations to requirements and deliverables and objectives, document everything, and review with the stakeholders to verify your understanding.
Guess what? Your stakeholders will change their minds. I can almost guarantee it will happen, regardless of how well you plan or how much time you spend gathering their inputs. It’s not personal. They’re not trying to make your life miserable, although it may feel that way. Circumstances and priorities change, and there are a lot of legitimate internal and external reasons to re-evaluate the project’s objectives. End-users and competitors don’t wait idly until you make your next move. The remaining cost of your project will be continually compared with other strategic opportunities. The unique nature of your project may assume the use of unproven technology or processes that are later found to be ineffective after trials or prototypes.
We shouldn’t be surprised. Project planning should always include some assessment of risk, including the risk of a major project re-set as a result of new stakeholder input. The correct response from the project manager is not aggravation, but rather an honest and objective reassessment. It’s important to reconvene all the key stakeholders and make sure everyone understands the possible impact to project schedule, budget, resources, and quality. One of the most valuable and underrated skills in project management is adaptability. You’ll be in a constant state of frustration without it.
PMP Certification Exam, Lessons Learned October 20, 2012
Posted by Tim Rodgers in Management & leadership, Project management.Tags: management, product development, project management
add a comment
I’ve been busy for the last couple of weeks studying for the PMP exam (I passed) and that hasn’t left much time for writing, but now I’ve got some time to reflect. I came up through the ranks as a project manager, learning through trial-and-error, and it’s been interesting to contrast those experiences with the standard processes and tools recommended by the Project Management Institute (PMI).
The product development projects that I’ve managed or participated in have typically followed a well-defined lifecycle with phases and formal checkpoint meetings. The phase checkpoints were theoretically go/no-go gate reviews, but in practice they were project updates for senior management and an opportunity to re-visit objectives and priorities. A project’s activity list and work breakdown structure were based on templates from previous projects. Development cost was estimated at the beginning of the project and tracked during the project, but it was understood that additional money and resources would be available if necessary. Schedule was usually the overriding constraint in order to meet sales channel commitments, so we would spend a lot of time analyzing the critical path and critical chain.
I’m guessing that those descriptions are fairly typical for product development projects. To their credit, PMI makes it clear that each organization should customize the recommended project management processes to align with their business objectives, streamlining or even deleting processes if necessary. That’s generous, but now that I’ve completed the training for the PMP exam there are three process areas that I’d like to emphasize in future product development projects:
1. Project charter and stakeholder management processes. In the future I want to spend more time formalizing the project charter, getting alignment, and clarifying the expectations of all stakeholders, not just the project sponsor. It’s not a good idea to wait until checkpoint meetings to discover a mismatch in priorities.
2. Formal change management processes, especially for scope creep. As a project manager I had a lot authority over scope changes, but the complexity of the design, the geographically-dispersed project team, and the influence of functional managers often made it difficult to stay informed. I want to help the team and stakeholders understand the risk to schedule when there’s a weak commitment to change management.
3. Risk analysis and management processes. In our projects we didn’t ignore risk, but I think the culture placed a higher value on firefighting instead of fire prevention. We should have spent more time assessing risk and looking for ways to avoid or mitigate.
I’d be willing to bet that these areas are not given enough attention in the majority of projects, especially when organizations become complacent. In my next job I’ll be the new guy, and that will give me the chance to ask the questions and perhaps challenge the assumptions that have governed previous projects. I’m looking forward to applying some new lessons learned.
Joining a Software Project In-Progress July 11, 2012
Posted by Tim Rodgers in Management & leadership, Product design, Project management, Quality.Tags: leadership, product development, project management, software development
add a comment
Yesterday a question on LinkedIn caught my eye: “What are 3 key metrics you use to assess [the] health of a given project? … Do you have your own checklist to use when being added to [an] already running project?” The person who posed the question identified themselves as a software developer, so my answer assumed a software project.
If I’m limited to only three metrics, here’s my checklist:
1. Schedule status: how far behind is the project vs. the original plan? You can’t change the past, but the actions you take from this point forward depend on how far behind you are now.
2. Scope creep and requirements stability: what is the weekly trend in requirements changes? What you’re looking for here is convergence on a fixed set of requirements. On-going turmoil and failure to converge is a red flag for both schedule and quality.
3. Defect management: what is the weekly trend in new, open, and closed defects? Is the team keeping up with defect fixing, or is there a growing backlog that will eventually overwhelm them?
With this information a project manager who joins a software development project in-progress should have a good idea of the current status. Certainly there are other things that would be worth knowing, for example the “validated completeness” of individual functional requirements, as determined by test results.
Needed: More Ideas Than Programs June 25, 2012
Posted by Tim Rodgers in Management & leadership, Product design, Project management, strategy.Tags: leadership, management, product development, project management, strategy
add a comment
In an earlier post I told the story of a senior manager who was fairly new to his executive position (Power: Use It or Lose It). He took advantage of an early opportunity to exercise his positional authority and refused to give the go-ahead to a program team that failed to meet the requirements for a phase gate checkpoint. What made this event especially surprising was that this particular checkpoint meeting was supposed to provide the high-level authorization to move from the initial “investigation phase” to the “development phase.”
In theory, and according to our documented product development lifecycle, this checkpoint was a go/no-go decision point for the program, and approval meant a commitment to invest the necessary time and money to bring the concept to market. The problem was that until that senior manager withheld his approval, I don’t recall any program that was rejected or even delayed at that early stage.
Was that because all of the previous programs were brilliantly-conveived and certain of success? Not at all. Some of them in fact proved to be classic examples of “technology driven” programs with impressive features that failed to address customer needs, or weak derivatives and product extensions that failed to anticipate competitive threats or provide other advantages to justify the development expense. Instead of providing a critical and objective assessment of the proposal’s contributions, the program team and their supporters would convince themselves that at least it was better than the alternative, which was essentially no program at all.
But, why were there no other alternatives? Shouldn’t a product development organization fund multiple low-cost / low-risk investigations, evaluate them objectively, and then recommend the most promising for commercialization? I don’t know what the ideal ratio is, but a business that approves 100% of the product concepts presented for further development surely isn’t trying hard enough. Senior leadership can set the tone by encouraging their development teams to generate ideas, and rejecting the cultural “fear of failure” that causes everyone to set their sights lower.
How Do You Plan to Catch Up? June 12, 2012
Posted by Tim Rodgers in Management & leadership, Project management.Tags: leadership, management, problem resolution, process, project management, software development, software quality
add a comment
When a project falls behind schedule — as it almost inevitably does — there’s a tendency for project managers and their teams to enter a state of denial and convince themselves that they can catch up by “working harder.” Maybe they remembered an earlier stretch when they weren’t working especially hard, maybe thinking there were still many weeks or months of budgeted time. Perhaps they encountered a barrier that couldn’t be easily overcome right away, and decided to “work around it” and come back to it later. Senior managers who are responsible for providing oversight to the project teams may accept this “working harder” plan, either because they’re sympathetic or don’t want to be bothered with the details.
How often does that actually succeed? Senior management shouldn’t accept an explanation that the project team will simply “work harder.” They should require the project team to explain how they will work differently. Doing things the same way is not going to help the team catch up; there needs to be a change in the scope of the project or how the work is done, for example adding resources, re-assigning tasks, or re-arranging tasks on the Gannt chart.
When I managed software testing we would track the number of defects found and fixed each week over the course of the project. The goal was always to have zero open defects by the time of the scheduled software release date. From historical data we had a rough idea of how many defects one developer could fix each week, so at any point in the project we could extrapolate an end date based on the number of open defects. If the extrapolated date was later than the scheduled date, we knew we were behind schedule and had find a way to catch up. In a case like this “working harder” means somehow increasing the rate at which the work (defect fixing) gets done, because continuing at the current rate was not going to reach the goal.
We used a variety of strategies, depending on the software project. Most often we would reduce the scope of the remaining work by de-rating defects and removing them from the fix queue, essentially accepting a lower level of quality. Sometimes we would add resources (developers) to fix defects, but anyone who has read “The Mythical Man-Month” from Fred Brooks knows that adding resources to a late software project just makes it later. We would finesse that problem by changing priorities and re-assigning tasks within the existing team instead of adding people (it didn’t always work).
Regardless, project managers shouldn’t be allowed to wave their hands and offer vague plans when projects fall behind. The catch-up plan must explain how things will be done differently, and it must be explicitly reviewed and approved by senior management to ensure a successful project completed without further surprises.
