Telirati Analysis #16 Practical project management

Software projects and traditional project management tools have always been a dangerous combination. But, you can understand the attraction: Gantt and CPM chart editors can be a delightfully visual way to plan a project. Even a novice gets a thrill of insight and the feeling of control.

Project management tools were originally made for creating big, expensive physical objects, like bridges, subway lines, and skyscrapers. These projects merited hiring professional project managers, and the nature of the projects left little room for ambiguity: Either 27 floors of steel are up, or not. Either the interior framing up to the 10th floor is ready for the electricians and plumbers, or not. In this world every measurement of task completion is represented by a physical object that can be directly inspected. Almost all the tasks in these physical-world projects have been done thousands, even millions of times before. Anomalies are relatively easy to spot, and few such anomalies are dangerous to an entire project.

The mismeasure of software

Contrast this with software development: If you use the same tools as people who build skyscrapers, you are locked-in to a largely "waterfall" model of development. That's out of fashion for good reason. The plan is rigid and subject to misreported completion. Projects die with 80% of every task complete but with few of them actually finished, done, put to bed. Many of these pathologies can be traced to two differences in software creation:

Software creation is all about doing new things. unlike buildings or roads, once you have built one kind of software, you can make a billion copies at negligible cost. So all new software is really new. Each significant task has never been done before and need never be repeated. If bridges were made of tens of thousands, or tens of millions of unique, hand-crafted parts, with the quality of each part highly dependent on the skill of the maker, you would find traditional project management tools completely inadequate to the task.

It is easy to mismeasure software task completion. Module tests tell you only so much. You can be convinced a task is complete and it is only half done.

Then combine the rigidity of traditional project management methods with misuse by inexperienced but enthusiastic software team managers and you have a truly deadly mix: "All these tasks can run in parallel, right?" "Resource leveling? What's that?"

Project management made for software

Software creation has bred it's own style, not to say dogma, of project management: Agile. As with other organized religions it is a canonicalization of a collection of possibly useful parables combined with a reframing of existing myths and some novel vocabulary for the priesthood to sling. Although the True Believers will tell you it's not a fault of Agile but rather the application, Agile has become notorious for allowing projects to run, incrementally, out of control, while providing the illusion of tight control.

We won't rehash all of it here, but suffice it to say that Agile has earned a backlash. Pathologies typical of Agile projects may well reflect problems in the organizations using Agile rather than Agile itself, but that's hardly an excuse, any more than the pathologies of traditional project management are an excuse for its unsuitability to software projects.

That said, Agile has key benefits:

• Accessibility and inclusivity in planning
• Agility: adapting a plan to changed requirements is easy
• Change tracking, accountability
• Done is done, and what's not done is tracked

How can we forge a practical, undogmatic tool set for software project management that works in the reality of how software is created? And, how can you, as someone not steeped in traditional project management and in Agile, feel confident enough to commit the heresy of a mixed approach?

For one thing, you can benefit from our experience. We use available tools in a practical combination, with some key goals in mind:

• Determine if a project is realistic, and go back to the basics of the idea if it isn't
• Keep tactical implementation decisions flexible
• Retain data for measuring plan-to-actual performance and other accountability metrics
• Don't bog a project down in replanning, but track changes

The most important overall goal is to retain the control over total project scope and cost that an up-front analysis provides while reaping as many benefits of Agile methods and tools as possible.

Toward a practical hybrid approach to project management

These are some of the ways we work toward those goals:

• Use a traditional resource-loaded CPM/Gantt chart project scheduling software package to find places where the project is resource-bound.
• Use resource leveling, either performing this aspect of planning manually, by using resource loading reports to identify over-committed resources, or by using automatic resource leveling if you have traditional project management software that has this capability.
• Find milestones that can be used to funnel multiple task completions to a choke point that must be completed before subsequent tasks are started, and get a best-estimate for total project completion. This is for planning only, not tracking.
• Defining a minimum viable product is very useful for planning. Take your task list and draw a horizontal line. Some tasks must be part of a minimum viable product (MVP), and some are not. Those go below the line. Make sure your project can reach a complete minimum viable product as quickly as possible. 
• When composing task "stories" do not allow those stories to stray outside the MVP definition, unless your project has ample slack to accommodate the extra work. You won't know that until late in the project's timeline.
• Use a "swim lane" style task manager to run tactical resource allocation and keep decisions about resources fluid enough to not be bound to a rigid waterfall process. JIRA, in particular, has more than enough parameters and options to be configured for a hybrid project management approach.
• Use your up-front project analysis as a way of preventing task-by-task mission creep. If a scrum adds up to a lot more hours than your up-front analysis predicted, review each task and watch that tasks do not stray beyond the functional requirements, and if they do, capture the intent by comparing stories to the preliminary task descriptions.
• Keep a version-controlled spreadsheet (Google Sheets is convenient for this purpose) that tracks added and deleted tasks and their resource and time estimates.
• Use milestones as gates that must be crossed before earlier parts of the project can be confirmed as completed. If the milestone is not complete, the project is in a state of day-for-day slippage.
• When creating scrum boards refer to the CPM chart and avoid spanning major milestones with sprints.
• Defer resource allocation to each sprint planning session to avoid locking the project into fragile up-front predictions about who should implement what.

This keeps a project nimble, not to say "agile," it provides adequate discipline before you find yourself at the end of the project schedule and are surprised it didn't all come together in the last week, and it gives me, as a consulting participant in projects, the documentation needed to take to a client when change requests add up and a re-estimation is needed, and it does so in a responsive framework that avoids re-bidding the whole project.