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.
Firing Customers For Profit November 7, 2013Posted by Tim Rodgers in Management & leadership, strategy, Supply chain.
Tags: business development, early stage companies, management, outsourcing, project management, strategy, supply chain
add a comment
Businesses large and small generally work diligently to satisfy customers, and they’re frequently reminded that the cost of acquiring a new customer is much greater than the cost of retaining an existing one. Unfortunately many of those businesses fail to appreciate that each customer has an incremental cost, not just to acquire, but also to manage. It’s possible that an organization can spend more money to support a customer than what they get in return, which is obviously an undesirable situation.
Early stage companies are particularly susceptible to this kind of trap. In their eagerness to turn their ideas into revenue, they will often incur hidden costs in order to customize products and services for each potential customer. Any customer who is willing to pay looks like a good customer. Geoffrey Moore writes about this in his excellent book “Crossing the Chasm” (HarperBusiness, 1991). The danger is that the company loses economies of scale, leverage and re-use efficiencies, and ultimately the focus that defined the unique profit opportunity in the first place.
Unprofitable customers or segments can be hard to detect. It’s easy to add up the direct material cost of a single product configuration, but you also need to understand how much time your sales and support staff spend with a customer. Does your purchasing team have to manage unique suppliers? Does your quality team perform special tests or inspections? Your indirect labor may be spending a disproportionate amount of time dealing with requirements and requests from customers who squeak.
Unprofitable customers are not necessarily bad for the business. Moore writes about segments with “bowling pin potential” that may be a net loss today, but enable the firm to establish foundational processes, move up the learning curve, and leverage and grow in the future. These loss-leaders have long-term strategic value, but it’s important to understand and assess the investment in order to ensure the expected return.
Actually refusing to do business with a customer is extreme and could hurt your reputation, but consider ways to reduce the cost to manage a customer that isn’t currently providing a net profit or enables future profitability. The firm that fails to understand their “cost to serve” may find itself out of business despite many happy customers.
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.
Decisions Based on Psuedo-Quantitative Processes December 28, 2012Posted 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, 2012Posted 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, 2012Posted 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, 2012Posted 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, 2012Posted 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, 2012Posted 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, 2012Posted 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.