Search This Blog

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.

Get link

Facebook

Twitter

Pinterest

Email

Other Apps

Comments

Post a Comment

Popular Posts

UPDATE
A continually updated version of the information in this post, plus a lot of new information, is now available at: 5Ggui.de
Telecom companies, their suppliers, and politicians are putting 5G in the news
There have been a lot of news stories about 5G, a new mobile wireless standard. The theme many of these suspiciously similar articles is that 5G is going to transform everything. I'll tell you what to expect in reality, and what is wishful thinking on the part of the telecom industry, and why telecom service providers and equipment makers are hyping fantasies.
5G is a better radio
5G means better mobile devices and a better mobile network. There are three main reasons 5G is better:5G introduces a new radio technology that makes more efficient use of radio spectrumThe network behind those radios will be faster and have lower latency5G enables using more of the radio spectrum
There are many factors in the increased sophistication in 5G radios. These are the most important:Encod…

At Google I/O 2016, Google announced two new messaging products: Allo, for text messaging, and Duo, for video communications. These are the most recent in a series of messaging products Google has created, none of which have succeeded in attracting a really large user community the way that other messaging products have done. Google doesn't release figures for monthly active users of Hangouts, while WhatsApp has a billion users, Facebook Messenger and QQ have 850 million, and WeChat has about 700 million. The stakes in messaging are very high, and, so far, Google is an also-ran.

In 2015, it looked like Google might go in a different direction, perhaps acting as a spoiler for proprietary messaging apps that don't interoperate and don't use carrier protocols like SMS and MMS. Google bought a company called Jibe that makes next-generation messaging servers for standard telecom protocols called Rich Communications Services, or RCS. If Google based a messaging system on RCS it w…

Photo by Matthew Hester (CC BY-ND 2.0)
Google has become something of a slumlord. While Google+ has been accused of being a "ghost town," at least it looks pretty, even now after what feels like a long period of stagnation and un-addressed bugs. But Google+ isn't the most neglected neighborhood in Googleland.

Where is the Blogger blog?
Various parts of Google, notably Search, use Blogger to convey news about new releases and their development road map. Blogger is key infrastructure for Google itself. But where is the Blogger blog? Like some other semi-abandoned properties, Blogger no longer has frequent updates about features.

If you want a history of Blogger and it's features, you'll have to rely on Wikipedia. Evidently there are ardent Blogger users who keep track of these things.

Why does this matter? There are a lot of abandoned places on the Internet. Blogger, however, is emblematic of the problems that precipitated the departure of Vic Gundotra from Google+…