8. Project Management¶

In preparing for battle, I have always found that plans are useless but planning indispensable.
— Dwight D. Eisenhower 

Focus: The Making of Smaug. 

As we’ve discussed but have yet to exactly define, a project is a temporary undertaking, planned and executed from beginning to end, involving personnel, equipment, and money, that produces a unique product or service. Accordingly, software project management is the “art and science” of administration in support of the development process, and focused on the end-result rather than implementation details.  Projects end when their objectives have been met, or are terminated due to failure or obsolescence.

As project management is an age-old  career in itself, we’ll be discussing the nutshell-version here, for the benefit of developers and those who would manage them. A Project Manager (or PM) may manage one large project, several smaller concurrent projects, or a series of versions under continuous operation (though this latter case is not technically a ‘project’).

8.1. Considerations¶

Cheap, Fast, Good—pick any two!
— Proverb

Fig. 8.1 Constraints Triangle: Scope, Cost, & Time¶

The foundation of Project Management is the deployment of resources within a triangle of constraints that limits us, nicknamed the “Iron Triangle.” The Project Management Institute’s Body of Knowledge  (PMBOK 5) defines the sides as Scope, Cost, and Time, and secondary factors of Risk, Resources, and Quality. Under this model, adding to one side e.g., increasing the scope, forces the the other sides (cost, time, or both) to expand to compensate. Let’s look at these terms more closely:

Scope:: The amount of work considered. What subset of functionality (from an infinite set of choices) do we plan to build during this project? This is the product scope. What is the work required to deliver a product of such scope? That’s the project scope.
Cost & Resources:: How much money, materials, and equipment? How many personnel are budgeted and available? Training, tools, caffeine, and the occasional dinner should be factored in. As first estimates tend to take on a life of their own, don’t be in a hurry to provide hard numbers until some certainty is achieved.
Time:: When must the product deliverable be released? Must we coordinate with other events, such as a trade show, or tax season? Don’t forget holidays, vacation, and sick time.
Risk:: What’s likely to go horribly wrong on this project? What can be done to mitigate or prevent such problems? What is “Plan B?” (Challenges are discussed further in the following chapter.)
Quality:: What are our non-functional requirements and goals related to Software Quality?

Additional constraints related to software projects include:

Backward compatibility
Hardware requirements
Overcommitment of team members

Industry norms and regulations
A limitation to problems that software can solve.

Anchoring the Triangle

If your customer won't give you a corner of the triangle, you usually can't do the project [successfully].
— Steve McConnell, Rapid Development (Ch. 6)

As Mr. McConnell alludes, project success requires at least one side/corner of the triangle to be flexible. If a client tries to nail you down on all three, run for the hills!

8.1.1. Roles¶

The quality of the people on a project and their organization and management, are much more important factors in success than are the tools they use or the technical approaches they take.
— Fred Brooks, The Mythical Man-Month, 2nd edition (Ch. 19)

As we discussed in the Requirements chapter, stakeholders are those that are invested in, integral to, and/or affected by the project. Discussed below are a number of others.

Project Sponsor:: The sponsor is a manager or executive with authority to commit resources and enforce decisions regarding the project.
Project Team:: Personnel assigned to the project, including the PM, Development team, Designers, QA team, Ops/Admins, etc. Architect: similar to the director of a feature film.
Subject Matter Expert (SME):: Consultants with expert-level knowledge in specific discipline(s), technologies, industries, or business areas.
Suppliers / Vendors:: Third-party companies and subcontractors supplying supplies, software components, technology platforms, or equipment. There may be engineering support and sales contacts.

Project Manager (PM):

The PM is one of the main drivers of the project, organizer, and a central point-of-contact, and often represents the voice of the customer in meetings when not available. Fred Brooks likens the position to the producer of a feature film. What is it like to be a PM? From Project Management 101 , Merrie Barron, PMP, CSM:

Well, you’ll have to know a little bit about just about everything. You’ll have to learn to pay attention to the details, but not get wrapped up in them. You’ll have to make countless decisions with insufficient information and despite conflicting signals. You’ll have to condition yourself to seek acceptable solutions, rather than perfect ones. You’ll have to blend technical expertise with a keen sense of human nature. You’ll have to handle administrative matters.

Generally a PM does not have authority to impose their will directly on the team, but is rather a participant among equals. An ability to influence others is vital, and so communication, persuasion, and consensus-building are requisite skills. Consequently, a project must also have the right sponsor. If the PM and sponsor together are not able to commit necessary resources or personnel to a project, it’s likely to fail.

See also: Online Resources

Project Roles and Responsibilities 

This post recaps the main roles in a software project.
The Many Roles in Software Projects 

Explains the multitude of roles available on a software project, branching out a few degrees into other disciplines.

8.1.2. Communication¶

~Ninety percent of a project manager’s time is spent communicating.
— Project Management Institute (PMI) 

High-quality communication is the greatest challenge of project management, and perhaps life in general. Information must travel from brain to brain to brain. We take highly complex mental states, factor by common lifelong experience, serialize into primitive noises (think 100 baud modem ), and bounce them through the atmosphere into the auditory canals of other sentient bipeds made of meat , who then reverse the process. Ideas are often flawed and imperfectly described, to put it mildly; errors in transmission abundant. It’s a constant challenge, when team members choose to speak at all that is. Stereotypical computer geeks can’t be bothered to speak up until the house is burning down. :-/

If you’re quiet by nature and managing a project your performance can be improved by consciously over-communicating. As a PM you’ll need to be asking questions all the time, and encouraging your team to ask them of you. Information must be free-flowing in all directions. Not all of it will be verbal of course, email should be used when things need to be specified more accurately and asynchronously. Further, the project will need to be documented, properly, of, course.

Fig. 8.2 How to write an e-mail… (to anyone), courtesy “Piled Higher and Deeper,” by Jorge Cham ¶

Communication Overhead

Everyone working on the same task needs to keep in sync, so as more people are added they spend more time trying to find out what everyone else is doing.
— Wikipedia 

Fig. 8.3 Combinatorial Explosion, courtesy geeklawblog ¶

Beware, as is demonstrated through the figure at right, the number of communication paths explodes as a team grows, using the simple formula:

 N * (N - 1)
────────────
      2

This formula grows at O(n²), to use big O notation . In computing this is referred to as a “combinatorial explosion” , and sounds like a great name for a band. While a three member team has a manageable three communication paths, a team of six already has fifteen, and it goes through the roof from there. While not every pair needs to communicate at once, it is a good illustration of how communication overhead grows in larger teams. From Code Complete (Ch. 27), Steve McConnell:

The more communication paths you have, the more time you spend communicating and the more opportunities are created for communication mistakes. Larger-size projects demand organizational techniques that streamline communication or limit it in a sensible way.

From The Mythical Man-Month (Ch 2.), Frederick P. Brooks, Jr.:

Since software construction is inherently a systems effort—an exercise in complex interrelationships—communication effort is great, and it quickly dominates the decrease in individual task time brought about by partitioning (breaking tasks apart).

On the demise of Netscape, this famous post-mortem:

The company stopped innovating. The company got big, and big companies just aren't creative. There exist counterexamples to this, but in general, great things are accomplished by small groups of people who are driven, who have unity of purpose. The more people involved, the slower and stupider their union is.
— Jamie Zawinski 

If you’ve heard the adage about how great things can be accomplished by small teams, this is the main reason why.

Frequently Asked Questions

Customers don't come up with totally new questions and problems day in and day out, and because the same ones tend to surface repeatedly, a manager can reduce time spent handling interruptions using standard responses.
— Andrew S. Grove, founder/former CEO Intel, "High Output Management" (Ch. 3) 

Finally, after the specs, are up to date, make sure F.A.Q.s  are recorded and answered as they come up. It’s wasteful for team members to squander time giving out the same answers over and over again, when they could simply dish out an URL or Q#.

Setting Expectations

If they expect a unicorn, it’s your fault.
— TeamGantt 

Setting realistic expectaciónes and keeping them updated is one of the most important parts of project communication. Just ask Wall Street —when there’s a mismatch between expectations and reality things get ugly fast. Make assumptions and intent known beforehand; set them early and often .

Expectations should be met progressively rather than in a single huge deliverable that requires clients to accept them in one bite.

The Other’s Shoes

When thinking, communicating, and documenting, put yourself in the other person’s shoes, just as $PARENTAL_UNIT taught you. What does the other person need to know, and how can it be presented in a way they can understand? 

Information Scarcity

If you fail to communicate, someone else will do it for you.
— Luckey/Phillips, Software Project Management for Dummies 

Gulp, yes when confronted by a lack of information, our brains want to fill in the blanks with anything they can latch on to—avoid by handling issues proactively—get out in front of them.

Meetings

Before you are horrified by how much time I spend in meetings, answer a question: which of the activities—information-gathering, information-giving, decision-making, nudging, and being a role model—could I have performed outside a meeting?
The answer is practically none; meetings provide an ocassion (medium) for managerial activities.
— Andrew S. Grove, founder/former CEO Intel, "High Output Management" 

There will to need be regular meetings (groan) to facilitate. Don’t consume everyone’s time of course—have an agenda, stick to it, and table tangential discussion until later. Yet, also beware of interruption; limit and group meetings as much as possible for the benefit of creative workers.

In the book Peopleware, authors DeMarco and Lister split meetings into two major kinds, the working meeting, where the minimum number of people necessary to achieve a goal are present and participants are dismissed upon completion. Secondly, the “ceremony” a time-boxed event that ends when the clock strikes. Ceremonies are said to be less efficient, since they tend to be serial F.Y.I. interactions with the boss. The time of the other (p - 2) participants is largely wasted. It recommends eliminating most ceremonial meetings:

Those who believe that meetings should be replaced with conversations observe that the one-on-ones might just as well take place somewhere else with all the rest of the participants released to do real work.

The ultimate management sin is wasting people’s time.

See also: Online Resources

Master the Art and Science of Meetings ,
A useful primer, courtesy Brett Harned @ teamgantt.

Handling Disagreement

Your experience/talent should dictate how much you press on an issue, and you should do it professionally regardless. Over the years I have encountered people arguing passionately about things that, as it turns out, they did not fully understand.
— makecheck on HN 

Disagreements will happen between individual members of the team on which direction to take the project. It’s important to remember that (normally) everyone on the team wants it to succeed and improve, so giving members the benefit of the doubt in that regard will make for less troubled interactions when differences inevitably occur.

To work towards resolution in a constructive manner, it’s recommended to take a similar strategy to risk management. Briefly, you’ll want to informally categorize and prioritize conflicts to decide which to persue—an idea also known as “picking your battles” . You’ve got a finite amount of energy and “political capital”  to make changes. Choose a few to care and speak up about for and let the rest slide.

Hint

To be clear, the term used here “picking battles,” doesn’t refer to a real argument, but merely a difference of opinion. On a healthy team these should be mild at best, noted and moved past.

The practice of egoless development and humanized feedback should help avoid team members taking decisions personally. The basics of negotiation are useful here as well. The chance of success greatly improves when the other person and team is helped forward, the proverbial win-win  situation.

8.2. Process¶

Fig. 8.4 PMBOK Groups¶

Of all the things I've done, the most vital is coordinating the talents of those who work for us and pointing them toward a certain goal.
— Walt Disney (Unconfirmed) 

The six phases of the software project process, as defined in the PMBOK  are listed below, each followed by where it roughly corresponds to the development life cycle:

Definition - Problem Definition
Initiation - Requirements
Planning - Requirements, Design
Execution - Construction
Monitoring & Control - Construction, QA/Testing
Closure - Release

The phases are also called “process groups,” as the central activities occur multiple times.

8.2.1. Definition and Initiation¶

Good judgment comes from experience,
and experience comes from bad judgment.
— Fred Brooks, University of North Carolina 

Numerous tasks need to be completed at the start of a large project. The problem must be defined, requirements gathered (“what do we need?”), a feasibility study done (“can we do it?”), and business case made (“should we do it?”). Prototypes may be created to flesh out concepts and test assumptions.

The selection of projects from a number of candidates, by executive team or sponsor may also be a consideration. Unless you’re at a non-profit, know that as always business concerns, i.e. costs, benefits, and profitability are the primary decision factors. For our purposes, imagine that your candidate project has been selected, approved, and funded—congrats! If only the rest were as easy.

Pilot Project

A pilot project is a preliminary project or trial performed in order to evaluate a new idea or technique. When implementing a pilot, experiment with one unfamiliar technique at a time. Remember, “It’s best to confuse only one issue at a time.”

Kickoff meeting

Fig. 8.5 How the PM understood it. ¶

The project kickoff meeting  is where the team and client(s) meet as a group for the first time, making introductions (if necessary), discussing plans, and setting expectations. Below are a number of questions to consider, courtesy D. Keith Robinson :

What are our goals for this project? (aka purpose)

Who are the stakeholders, and how to best get them involved?

What deadlines do we have to meet?

What roles will team members play? Does everyone know their role?

Have expectations been set clearly for everyone involved?

A sample agenda can be found at teamgantt :

Introductions
Review scope
Discuss the timeline
Discuss requirements

Discuss communications
Identify and discuss risks
Assign project roles
Talk about process

Warning: Early Overstaffing

Probably no more than 90 percent of all projects suffer from early overstaffing.
— DeMarco/Lister, Peopleware: Productive Projects and Teams, 3rd Ed. (Ch. 32) 

You may be pressured politically to staff up at the beginning of a project that’s under time pressure. Remember that due to communication overhead and emergent requirements many of those man-hours will be wasted. Experience has shown that software design of a substantial project is best done by a small team of “top” individuals. When the Construction/Execution processes begin is when the bulk of project staff should be gradually brought on board.

See also: Online Resources

The secrets to successful kickoff meetings, by Jerry Cao @ The Next Web 

Documentation

Sharing knowledge in a systematic format, documenting lessons-learned, and ensuring frequent communication will maximize project success factors.
— Scott Seningen, PMP 

At project initiation time, a number of new documents are created:

The Project Charter  contains relevant metadata about the project. “The project charter defines the scope, objectives and overall approach for the work to be completed.”   
- Assumptions are ideas believed to be true, but haven’t been proven. Treat assumptions carefully; those that are wrong may become risks.
A first version of the Software Requirements Specification (SRS) is completed.
The Work Breakdown Structure (WBS) discussed below, is started.
A product description, aka Functional Specs from the Design phase may already be in process, if the team is on its toes.
A Lessons Learned  document, to record successes and mistakes for future projects and managers, including yourself. The document should be created early so insights may be recorded right away, e.g. during a weekly meeting and not forgotten. Tips:
- A spreadsheet can provide more structure than a rich-text document.
- Keep out negativity, fight any urges to include.
- Revisit and finalize the document at Post-Mortem time.
Recording lessons learned can boost performance and give you an edge over the long term.

Finally, consider employing a technical writer if the project can afford it; well-written documentation is always a plus.

Work Breakdown Structure (WBS)

Once requirements are in and the project has been given the green light, a WBS  is a helpful way to visualize project deliverables graphically and get a handle on project scope. The graph is a tree-structure containing a hierarchical set of boxes representing the project, decomposed into its constituent parts and sub-components.

Fig. 8.6 An example WBS¶

As a general guideline, each box should take between eight and eighty hours to complete, aka the “8/80” rule. The structure typically extends three or more levels from the root. Software to create a WBS:

MindView  (Proprietary)

Dia  and Inkscape  (FLOSS)

8.2.2. Planning¶

Failing to plan, is planning to fail.
— Proverb

The planning phase is where developers design solutions and author functional specs, construction is scheduled, vendors and contractors are hired, and costs estimated to meet project objectives.

From “The Project Life Cycle,” Merrie/Andrew Barron, PMP, CSM :

The project’s tasks and resource requirements are identified, along with the strategy for producing them. A project plan is created outlining the activities, tasks, dependencies and timeframes. The project manager coordinates the preparation of a project budget; by providing cost estimates for the labor, equipment and materials costs.

Next, risks are identified, analyzed, and classified. Concurrently, a Quality Plan is authored by the QA team.

8.2.2.1. Release Cycle¶

Fig. 8.7 Release Cycle, courtesy Wikipedia ¶

The traditional software release cycle proceeds as described below.  As an interesting aside, the Greek letter scheme originated at IBM .

Development Milestones:: Shortly after Construction begins, a number of “milestones” are scheduled, corresponding to implementation deadlines or functionality ready for testing. Milestones should be concrete, measurable events.
Alpha, Feature Complete:: This milestone is for an internal, pre-announcement test. The software has implemented core features and unit-tests but is unstable; integration and system testing begins.
Beta, or Field Testing:: Beta starts when the product is feature complete and the obvious “low-hanging” bugs from alpha testing have been found and fixed. “Beta testers” are typically customers that have volunteered to try the immature software early in order to exercise needed new features, get familiar with new versions, and have some ability to influence development through their findings and feedback.

Defect reports are collected and worked on by the project team, with the goal of making the software useful to a growing number of customers.

Tip

When you do a beta test you’re not going to have a single beta tester who’s willing to install every single beta version of your software—and do a complete test from head to toe of that version. You’re going to have people who try it out on the first day; they’re going to report a bunch of bugs, and that’s going to be the last you hear from them. So if you have 500 beta testers, you need to give 50 of them each of 10 releases so that you actually get some feedback from the third, fourth, fifth, sixth, seventh beta.
— Joel Spolsky, Salon.com interview 
Release Candidate/Code Complete:: After a few Beta test cycles, the software project should stablize with fewer and fewer bugs found. This leads the team to declare a “release candidate,” which is distributed internally and externally for further testing.

Bugs found at this stage are strictly categorized. High priority blocking issues are fixed immediately, but lower priority are postponed until the next release in favor of stability. Code complete refers to the fact that no “new feature” code may enter the codebase, only fixes.
RTM/GA/Gold:: As stability is achieved, a “release to manufacturing” (RTM) is made if the project or clients are old-school and require physical media for whatever reason. For online products, the new software or version is promoted from a staging area to production. “General availability” ensues. This event corresponds with the Release stage of the SDLC.

Continuous B.I.G.

Consult the section on Continuous Delivery in the previous chapter for release under iterative or continuous operations.

8.2.2.2. Scheduling¶

The era of force must give way to that of knowledge, and the policy of the future will be to teach and lead, to the advantage of all concerned.
— Henry Gantt 

Fig. 8.8 Behold the all-powerful Gantt chart; the red bar is the “critical path.” ¶

Scheduling is the allocation of resources to complete project tasks over time. Most often on software projects this is done using a Gantt chart . Named after Henry Gantt and developed in the 1910s, it is a linear bar-chart quite helpful for visualizing the scheduling of a project over time. It has since become the foundation of project management planning.

With the WBS as the primary input, tasks and estimates are entered, then detailed until the project is fully scheduled. Gantt charts illustrate start/completion dates and dependency relationships in a straightforward manner. The PERT  chart is another type of flow chart that focuses on task relationships and can grow to be very complex.

When scheduling, beware of packing work too tightly. Charles Portman, manager of International Computers Limited (ICL)’s Software Division at Manchester (via MMM) found:

Programming teams were missing their schedules by about one-half—each job was taking approximately twice as long as estimated.

Logs showed that the estimating error could be accounted for by the fact that his teams were only realizing 50 percent of the work-week as actual programming and debugging time. Machine downtime, higher-priority short unrelated jobs, meetings, paperwork, company business, sickness, personal time, etc. accounted for the rest.

Critical Path

A special focus is made on finding the “critical path,” the longest sequential path of dependent tasks on the project (see Fig. 8.8). The concept is called the limiting step, in Andy Grove’s High Output Management :

The key idea is that we construct our production flow by starting with the longest (or most difficult, sensitive, or expensive) step and work our way back.

If any sub-tasks on this path are late or delayed, the whole project will miss its deadlines. 

8.2.2.3. Estimation¶

It is the mark of an educated man to look for precision in each class of things just so far as the nature of the subject admits.
— Aristotle, Book I 

In this part of the Planning phase, tasks are assigned probable completion times and placed into the Gantt chart. In the book Rapid Development, Steve McConnell writes:

The basic software-estimation story is that software development is a process of gradual refinement. You begin with a fuzzy picture of what you want to build and then spend the rest of the project trying to bring that picture into clearer focus. Because the picture of the software you’re trying to build is fuzzy, the estimate of the time and effort needed to build it is fuzzy, too. The estimate can come into focus only along with the software itself, which means that software-project estimation is also a process of gradual refinement.

This model of software estimation recommends giving ranges instead of single values when giving estimates. This is useful because it reinforces the idea that the scope of the project is in the process of coming into focus, and will improve as the schedule progresses. Recommended range multipliers, adapted from “Cost Models for Future Software Life Cycle Processes: COCOMO 2.0” (Boehm et al. 1995, McConnell 1997):

Table 8.1 Estimate Multipliers by Project Phase¶
Milestone	Optimistic	Pessimistic
Initial product concept	0.25	4.0
Approved product concept	0.50	2.0
Requirements spec	0.67	1.5
Product design spec	0.80	1.25
Detailed design spec	0.90	1.10

To use these multipliers, first take your best single-value estimate and multiply it by the optimistic and pessimistic values and return them as a range. The multipliers above are for “gut feeling” type of estimates. If you’ve done additional work—counting modules and function points, consulting historical data, consulting schedule tables, etc—you can use these more constrained values instead: 0.60-1.60, 0.80-1.25, 0.85-1.15, 0.90-1.10, 0.95-1.05.

These multipliers describe what is known in software project estimation as the “cone of uncertainty.” Let’s take a look at an example project estimated at 100 man-months (mm) to see what it can tell us:

Table 8.2 Example of a Range-Estimation Project History
(of 100 man-months)¶
Milestone	Estimate given (mm)
Initial product concept	25-400
Approved product concept	50-200
Requirements spec	90-200
Product design spec	120-180
Detailed design spec	145-180
Final	170

Hint: Estimate Perception

Note how the ranged estimates above (compared to a final result of 170 mm) will most likely be viewed as a success, while a single value estimate given instead (100 mm) would appear to be a failure.

Further considerations:

Estimation must take into account the kind of software being built (program, system, product).
Adding conditions to an estimate rarely works, as they are promptly forgotten when the message is relayed to the next person.
Don’t omit oft-forgotten common tasks and time-sinks such as, cutover, installation, customization, maintenance, coordination, review, vacation/holidays/sick-time, meetings, and training.
Estimate at a low level, rather than high level for better results. (Lederer and Prasad 1992)
“Avoid off-the-cuff estimates. Developers are sometimes trapped by off-the- cuff estimates.”
Avoid “padding” in favor of ranges with refinement.

Estimation Accuracy

Never, ever let managers tell programmers to reduce an estimate. The schedule is not the place to play psychological games.
— Joel Spolsky, "Evidence Based Scheduling" 

Always give accurate (to your knowledge) and current estimates and do not let pressure or the perception of pressure convince you to change them. The main reason being that you “can’t negotiate the laws of nature.” A schedule is like a “box of wood blocks,” they can’t be forced into too-small a container without damage.

You’re probably thinking, “Yeah—easier said than done,” right? Indeed, however when a schedule is changed due to pressure, it is knocked abruptly into the realm of fantasy—setting everyone up for disappointment later on—too late for course correction. Unfortunately, it’s an “orcs storming the gates”  type of fantasy, not the “owning a Caribbean island” kind.

When dealing with such pressure (without slack given on the other sides of the triangle), rephrasing as a question may help, e.g.: “would you like to be disappointed now, or later?”

See also: Online Resources

Batten down the hatches and endure the thunderstorm of an unwelcome estimate early in the project instead of the hurricane of schedule slips and cost overruns later on.
— Steve McConnell 

Software Estimation Is A Crock, by thecodist 
Estimating like an Adult – What to Steal from Agile… by Write More Tests 
The Ten Deadly Sins of Estimation,
courtesy of Steve McConnell:  
1. Confusing targets with estimates.
2. Saying “yes” when you really mean “no”.
3. Committing to estimates too early in the cone of uncertainty.
4. Assuming underestimation has no impact on project results.
5. Estimating in the “impossible zone”.
6. Overestimating savings from new tools or methods.
7. Using only one estimation technique.
8. Not using estimation software.
9. Not including risk impacts in estimates.
10. Providing off-the-cuff estimates.
How to Defend an Unpopular Schedule,
Steve McConnell, Best Practices column, IEEE Software.  

8.2.2.4. Counterproductive Deadlines?¶

…you can plan for work to be done on a deadline but you can't [realistically] negotiate when it will be done by those doing the work. It's going to take as long as it takes.
— agentultra on HN 

Another approach from the trenches surfaces in this long-form article  at apenwarr.ca and its associated discussion.  Its TL;DR is that you should not talk about hours or deadlines with engineers. Instead we compare team velocity against abstract “story points”  to come up with estimates for the business. The story points relate to relative task size and complexity rather than the number of hours to anticipated completion. Given a velocity one can work backwards to find a scope that satisfies the deadline.

The claim is that this disconnection resolves many psychological issues inherent in larger projects such as “student syndrome,” a.k.a. putting things off until the last minute, in favor of a steady pace. (Issues discussed further in the next chapter.)

8.2.3. Execution¶

It's time to kick ass and chew bubblegum, and I'm all outta gum.
— Duke Nukem 3D 

With the “ink drying” on the documentation, the bulk of the planning process is now over. The Execution phase is where the primary work on the project is done. Software Construction begins in earnest and the team gets to work. At this point the PM shifts into communicating status, updating documentation, and managing conflicts, not only among people but between expectations and reality.

The Project Management Institute  (PMI) outlines these nine knowledge areas  in their PMBOK. Each is performed in support of the project:

Scope Management
Time Management
Cost Management
Quality Management
Risk Management

Human Resources Management
Communications Management
Procurement Management
Integration Management

Wow, (you may have thought PMs just sat around , flapping their gums ). The outputs of the Execution process are the deliverables of the project.

8.2.4. Control¶

When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind.
— William Thomson (Lord Kelvin) 

The Monitoring & Control process group is the twin of Execution and focused on its observation.  Progress and performance is monitored continuously by PM, Dev, and Quality leads, focusing on variance  from the original plan. In other words, we measure where we are and compare with where we planned to be. Meanwhile, stakeholders are kept up-to-date at regular intervals.

The main purpose of this process is to identify issues as soon as possible and take corrective action(s) to mitigate them. This is another area where accuracy in reporting is paramount—always “tell the truth, even when it hurts.” 

See also: Online Resources

What gets measured, gets done.
— Tom Peters 

NASA’s Software Measurement Guidebook is a free, comprehensive guide on the subject.   

Measurement Pitfalls

When a measure becomes a target, it ceases to be a good measure.
— Goodhart's Law 

What happens when we fall in to the all-to-common trap of focusing on metrics at the expense of real goals? Folks will tend to react with whatever solution is under their control to meet them. For an example that will make you want to cry in your Wheaties,  read this piece (courtesy Katrina Brooker writing for Fortune Magazine), on the demise of the PC manufacturer Gateway, Inc.: 

One policy put a time limit on customer-service calls; reps who spent more than 13 minutes talking to a customer didn’t get their monthly bonuses. As a result, workers began doing just about anything to get customers off the phone: pretending the line wasn’t working, hanging up, or often–at great expense–sending them new parts or computers. Not surprisingly, Gateway’s customer satisfaction rates, once the best in the industry, fell below average.

Warning: Measurement Pitfalls

Understand that software measurement is a means to an end, not an end in itself.
— NASA Software Engineering Program

Don’t get carried away with metrics, as Steve McConnell concurs in Code Complete (Ch. 28):

Be aware of measurement side effects. Measurement has a motivational effect. People pay attention to whatever is measured, assuming that it’s used to evaluate them. Choose what you measure carefully, as people tend to focus on work that’s measured and to ignore work that isn’t.

“No Excuses!”

And it can get much worse than mere negligence when employees are backed into corners by unrealistic goals, including illegal activity. You may have heard about how unreasonable sales targets were met  at Wells Fargo recently (TL;DR—Fraud). Here’s another striking example from the educational world highlighting the results of rigid adherence to benchmark targets combined with associated bonuses and terminations. How and why convicted Atlanta teachers cheated on standardized tests,  from the Washington Post:

An Atlanta jury convicted eleven teachers of racketeering and other crimes in a standardized test-cheating scandal — not by students but by teachers and administrators who were under pressure to meet certain score goals at the risk of sanction if they failed.

8.2.4.1. Managing Changes¶

Ch-ch-ch-ch-changes
(turn and face the strain)
Ch-ch-ch-ch-changes…
— David Bowie, Hunky Dory 

As a project progresses, some assumptions will turn out to be naïve or just plain wrong. In fact, requirement changes are inevitable on projects of any significant size and length, and increases in its scope can threaten it. Consequently, to protect a project and keep it healthy, any significant modifications should pass through a “change control” process, headed by a change control board  or (CCB). A CCB supervises and approves of new requirements, or the remediation  of mistaken ones. Proposals should be tracked in a database or spreadsheet. It may sound stuffy and formal, but doesn’t have to be so. Simply gather the principals—key stakeholders or their representatives, dev lead, and PM at a table (or online meeting) and vote. Prior to voting, the proposed change is vetted, valued, and estimated beforehand. Ch-ch-ch-ch-changes to the schedule and budget will be significant points of discussion. If not approved, proposals may be postponed to a future release.

Hint: Stakeholder Influence

Over the course of the project stakeholder influence should wane, putting a damper on last-minute changes.

8.2.5. Closure¶

It's time… to come together ♪
It's up to you, what's your pleasure?
— Kool and the Gang, "Celebration" 

Fig. 8.9 For all that you do…  ¶

After acceptance testing is complete, remaining bugs have been fixed or postponed, and the software and docs have been delivered to the client, the project is ready for closure. Additional loose ends to tie up will be the release of project resources, closing of supplier contracts, retrieval of signatures/payments if necessary, and communication with stakeholders. A maintenance team will need to be assigned or hired PDQ  (rápidamente).

The final step is to conduct the project review meeting, as discussed below.

8.2.5.1. Post-Mortem¶

This is the end, beautiful friend ♪
— The Doors, "The End" 

In the spirit of “continuous improvement”, the project review, aka retrospective, or “post-mortem” meeting is performed shortly after the project ships. While it should probably be called a post-partum (after birth) rather than post-mortem (after death), you’ll get weird looks if you try.

The purpose is to list the significant successes and failures of the project and learn from them, improving future team performance. Open discussion at this “roundtable” meeting is complimented by a review of the lessons-learned document to help jog the memories of participants. It should go without saying, but it’s important to avoid negativity and accusations and focus on procedural and factual improvements.

Finally, the lessons-learned document is updated and finalized with results of the meeting. The document must be available for reference to be useful; make sure to keep it easily accessible.

See also: Online Resources

Nine steps to IT post-mortem excellence, by ZDNet 

“Most IT project post-mortems are exercises in finger-pointing and assigning blame. Here are nine steps to make them useful.”

8.2.6. Maintenance¶

Nothing is as simple as it seems at first,
or as hopeless as it seems in the middle,
or as finished as it seems in the end.
— modt (Message of the Day) 

This section is a short reminder that the documentation artifacts of project management are similar to those of Software Engineering—frequently changing and in need of maintenance. Outdated documents become useless, so keep them up to date!

8.3. PM in a Nutshell¶

The manager's function is not to make people work,
it is to make it possible for people to work.
— DeMarco and Lister, Peopleware: Productive Projects and Teams

“Help, I’m in a nutshell!”

Below are several step-by-step lists helpful for those new to Software Project Management, who need a bit of hand-holding the first time or three.

8.3.1. Project Management Made Easy¶

Helpful high-level tips  for small to medium projects, courtesy D. Keith Robinson:

Don’t make it harder than it is.

Kick off strong and with clear documentation.

Stick to high-level milestones.

Always make sure expectations are set and understood.

Trust people to do their jobs.

Be a great communicator at all times.

Have a solid yet flexible process.

Use tools that work for you, not the other way around.

8.3.2. ProjectManager.com Guide¶

Focused on medium-sized projects, this Quick Guide: 12 Steps to Planning a Project, is courtesy ProjectManager.com :

Define the scope, the tasks to be completed.

Identify/connect with project supporters, aka stakeholders.

Determine available resources, in-house or outsourced.

Check the timeline

List the big steps, to capture big picture.

Break down into smaller steps

Develop a draft plan, with dependencies.

Create your baseline project plan, get feedback.

Refine the plan based on reality

Monitor progress, track daily

Document everything, especially changes.

Keep everyone up to date.

8.3.3. Association of Project Managers¶

APM’s Twelve steps to Project Management(aiming at larger projects) as explained by trainer Chris Croft  :

Planning Stage: Define the project, success criteria, and major constraints with the customer.

Which is the key driver: cost, quality, or time?

Don’t agree to a project you cannot deliver; don’t say maybe!

Deliverable: Project Inititiation Document (PID) or charter.

List the tasks.

Break the list into a tree diagram of tasks.

Deliverable: Work Breakdown Structure (WBS)

Consult an expert and/or history.

Estimate the tasks and costs for each task.

Time vs Cost, pad for risks.

Don’t promise the average or there’s a 50% chance you’ll fail to deliver. Better to promise “halfway between the average and the worst case.”

Asssess dependencies and produce a Network Diagram, aka Critical Path Diagram.

Easiest way to make a “post-it note” diagram on a white-board.

Heart of planning: this is where we decide how to actually “do” the project.

Find the longest path, the critical path, and how long it will take.

Consider overlapping critical tasks if it will take too long.

Increase resources (costs), reduce quality or both.

Adjust the tasks on the critical path first; note whether floating tasks become critical as the critical path is shortened.

Produce a Gantt Chart for the project.

Put in the critical path first.

The floating tasks “hang off” the critical path.

Each person can see their part of the project on the timeline.

Can look vertically to see when you’ll be busiest; calculate labor levels; slide floating tasks to reduce congestion.

Calculate resource requirements over time.

“Add up vertically”

Perhaps even add up /all/ your projects; add up all “resource profiles”

Assess risks (what might go wrong?)

How can we make it less likely?

Or less serious?

Commit to the project or not (loop back to step 1.)

Be assertive!

Use the Gantt Chart as an “arguing tool.”

Action Stage: Monitor Progress

“Color in” the Gantt Chart

Monitor Finance (Compare progress above vs. finances)

Reschedule

Ask for more money or time, did you pad for risk in step 3?

Review, what have we learned?

What went well? What didn’t?

What could we have done better?

Four Main Problems of Project Management:

Customer unhappy with finished result.

Avoid by defining result in (higher-detailed) writing from the outset.

Over Budget, avoid by:

Taking sufficient time to list tasks.

Getting every change signed for.

Estimating “halfway between the average and the worst case”.

Late due to problems arising:

Reduce scope.

Refocus on quality and bug-fixing.

Avoid by having a risk plan with contingencies for both progress (time) and cost (money).

Monitor progress, monitor cost; compare the two.

All of the above

Avoid by learning from previous projects by doing a review.

Store all project reviews for easy access.

8.4. Tools¶

The field for Project Management tools is pretty crowded, here are a few of the more commonly known:

Microsoft Project  (GUI, Proprietary)
Basecamp  (Web, Proprietary)
Wrike  (Web, Proprietary)
Teamgantt  (Web, Proprietary)
Jira  (Local Web, Proprietary)

Taiga  (FLOSS)
Odoo  Suite (FLOSS)
LibrePlan  (FLOSS)
Tuleap  (FLOSS)

See also: Online Resources

Top 11 Open Source Project Management Tools for 2016 
Project Management 101, Courtesy CONNEXIONS  @ Rice University :

John was given the responsibility for getting the job done but had very little authority to see to it that his decisions were implemented… Among your most valued tools will be the ability to persuade and influence.
— Project Management 101

This online course focuses to a greater extent on office politics and interpersonal concerns. While important components of Project Management, they’re beyond the scope of this book, and therefore recommended if you’re interested in the subject.