The project manager receives yet another suggestion from their boss to add to th
ID: 355491 • Letter: T
Question
The project manager receives yet another suggestion from their boss to add to the project's scope. Earlier requests were easy to address. They cost little in time, effort or money so the project manager simply addressed it within the team by calling in favors and working a few extra hours. This latest request from the boss is substantial. It comes as a result of seeing the great results your team has produced so far. This new suggestion has potential for great competitive advantage, but is well outside the scope of the existing project. The project manager to-date has simply absorbed any additions to scope.
What should the project manager do now? Will this project ever end? Are the project team members being punished for their good work?
A reference would be nice for further study
Explanation / Answer
Together, the practices in these five categories define a project management control system that can help your project deliver on expectations.
Laying the Groundwork
1: define a Success criteria
These business goals should imply specific project success criteria, which should again be measurable and trackable. They could include achieving schedule and budget targets, delivering committed functionality in a form that satisfies customer acceptance tests, complying with industry standards or government regulations, or achieving specific technological milestones.
Also, keep your eye on team member job satisfaction, sometimes indicated by staff turnover rate and the willingness of team members to do what it takes to make the project succeed. The business objectives define the overarching goal, though. It doesn't matter if you deliver to the specification on schedule and budget if those factors don't clearly align with business success.
Remember that not all of these defined success criteria can be your top priority. You'll have to make some thoughtful trade-off decisions to ensure that you satisfy your most important priorities. If you don't define clear priorities for success, team members can wind up working at cross-purposes, leading to frustration, stress, and reduced teamwork effectiveness.
2: Identify project drivers, constraints, and degrees of freedom
Every project must balance its functionality, staffing, cost, schedule, and quality objectives [Wiegers, 1996]. Define each of these five project dimensions as either a constraint within which you must operate, a driver strongly aligned with project success, or a degree of freedom you can adjust within some stated bounds. There's the bad news: not all factors can be constraints and not all can be drivers. The project manager must have some flexibility to react to schedule slips, demands for increased functionality, staff turnover, and other realities.
A "flexibility diagram" such as that shown in Figure 1 visually depicts your constraints, drivers, and degrees of freedom. A constraint gives the project manager no flexibility in that dimension, so it is plotted at the zero value on its axis. A driver yields a small amount of flexibility, so its point is plotted a bit higher than zero. Degrees of freedom provide varying degrees of latitude. They represent parameters the project manager can adjust to achieve the project's success drivers within the limits imposed by its constraints. Connecting the five plotted points creates an irregular pentagon. The smaller the area inside the Pentagon, the more constrained the project is.
I once heard a senior manager ask a project leader how long it would take to deliver a planned new large software system. The project leader replied, "Two years." The senior manager said, "No, that's too long. I need it in six months." The project leader's response was simply, "Okay," despite the fact that nothing had changed in the few seconds of that conversation to make the six-month target achievable. A better response would have been to negotiate a realistic outcome through a series of questions such as the following:
3: Define product release criteria
Early in the project, decide what criteria will indicate whether the product is ready for release. Possible release criteria might include the following:
Whatever criteria you choose should be realistic, objectively measurable, documented, and aligned with what "quality" means to your customers. Decide early on how you will tell when you're done, track progress toward your goals, and stick to your guns when confronted with pressure to ship before the product is ready for prime time.
Carefully consider your target market segments when deciding on release criteria [Rothman, 1999]. The early adopters and enthusiasts have a higher tolerance for defects than do the pragmatic early majority of customers or the conservative late majority. In contrast, time to market and innovative features or technology usage are most important to the early adopters.
4: Negotiate achievable commitments
Despite pressure to promise the impossible, never make a commitment you know you can't keep. Engage in good-faith negotiations with customers, managers, and team members about goals that are realistically achievable. Negotiation is required whenever there is a gap between the schedule or functionality the key project stakeholders demand and your best prediction of the future as embodied in project estimates. Principled negotiation involves four precepts [Fisher, 1991]:
Any data you have from previous projects will help you make persuasive arguments, although there is no real defense against truly unreasonable people.
5: Write a plan
Some people believe the time spent writing a plan could be better-spent writing code, but I don't agree. The hard part isn't writing the plan. The hard part is actually doing the planning-thinking, negotiating, balancing, asking, listening, and thinking some more. Actually writing the plan is mostly transcription at that point. The time you spend analyzing what it will take to solve the problem will reduce the number of surprises you have to cope with later in the project. Today's multi-site and cross-cultural development projects demand even more careful planning and tracking than do traditional projects undertaken by a co-located team.
A useful plan is much more than a schedule or work breakdown structure of tasks to perform. It also includes:
6: Decompose tasks to an inch-pebble granularity
You can track progress based on the number of inch-pebbles that have been completed at any given time, compared to those you planned to complete by that time. Defining the project's work in terms of inch-pebbles is an aid to tracking status through earned value analysis.The earned value technique compares the investment of effort or dollars that you've made to date with progress as measured by completed inch-pebbles.
7: Develop planning worksheets for common large tasks
If your team frequently undertakes certain common tasks, such as implementing a new object class, executing a system test cycle, or performing a product build, develop activity checklists and planning worksheets for these tasks. Each checklist should include all of the steps the large task might need. These checklists and worksheets will help each team member identify and estimate the effort associated with each instance of the large task he must tackle. People work in different ways and no single person will think of all the necessary tasks, so engage multiple team members in developing the worksheets. Using standard worksheets will help the team members adopt common processes that they can tune up as they gain experience. Tailor the worksheets to meet the specific needs of individual projects.
8: Respect the learning curve
The time and money you spend on training, reading and self-study, consultants, and developing improved processes are part of the investment your organization makes in project success. Recognise that you'll pay a price in terms of a short-term productivity loss when you first try to apply new processes, tools, or technologies. Don't expect to get fabulous benefits from new software engineering approaches on the first try, no matter what the tool vendor's literature or the methodology consultant's brochure claims. Instead, build extra time into the schedule to account for the inevitable learning curve. Make sure your managers and customers understand the learning curve and accept it as an inescapable consequence of working in a rapidly changing, high-technology field.
9: Don't schedule multi-tasking people for more than 80 percent of their time
The task-switching overhead associated with the many activities we are all asked to do reduces our effectiveness significantly. Excessive multi-tasking introduces communication and thought process inefficiencies that reduce individual productivity. I once heard a manager say that someone on his team had spent an average of eight hours per week on a particular activity, so she could do five of them at once. In reality, she'll be lucky if she can handle three such tasks. Some people multi-task more efficiently than others. If some of your team members thrash when working on too many tasks at once, set clear priorities and help them succeed by focusing on just one or two objectives at a time.
10: Record estimates and how you derived them
When you prepare estimates for your work, write down those estimates and document how you arrived at each of them. Understanding the assumptions and approaches used to create an estimate will make them easier to defend and adjust when necessary. It will also help you improve your estimation process. Train the team in estimation methods, rather than assuming that every software developer and project leader is instinctively skilled at predicting the future. Develop estimation procedures and checklists that people throughout your organisation can use.
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.