Both questions are hard to answer accurately, he says. It’s even harder to be both accurate and meaningful.
De Luca, a project manager and consultant with a Melbourne consulting practice, Nebulon, was sharing his project management experience at Borland seminars in Auckland and Wellington earlier this month. Titled “Visibility and value in development projects”, De Luca’s presentation discussed ways project managers can accurately predict the duration of a project. He suggests a six-month project estimate can be confidently confirmed or rejected in the first week of development, for example.
A few traditional favourites of project managers were discarded during his talk, such as Gantt charts and frequent, fixed milestones.
De Luca favours feature-driven development (FDD), an "agile" methodology that advocates building a project according to a list of features that the project team defines with the customer. He’s quick to point out, however, that no methodology holds all the answers.
“There’s no silver bullet,” he says. “I’m not religious about this stuff. I’m not religious that, for example, FDD is the only way to do this. What I am religious about though is the result, that we get things in on time and budget, reliably and repeatedly.”
De Luca sets out three requirements for project managers: visibility into the software development lifecycle; organised work breakdown structures for communicability and value; and predictive metrics based on early available indicators.
To achieve this trio of goals, he suggests project managers and customer first create a statement that defines the system to be built, and forms the basis of a loosely-defined overall model. The customer should be involved, as this model generally defines the customer’s business.
English is not the best language to define the model, De Luca says: “There’s too much wriggle room in the English language.” Instead, he recommends the unified modelling language, UML.
The customer and the project team can then create the list of features needed. Features are simple statements of simple functionality. They should be graded by difficulty: simple, medium or complex.
“No features can take more than 10 days to design, code, test and integrate,” De Luca says. A typical feature should take two or three days to deliver.
“You should only put a relationship between two jobs when they absolutely are dependent.”
De Luca separates projects into the startup phase — develop the overall model, build the features list and planning — and the construction phase, designing and building. As a rule of thumb each week spent in the startup phase will need about three months in construction, he says.
That means the startup phase should run for a month or less. “Not many people are interested in jobs that run for more than a year.”
De Luca limits milestone delivery dates to a specific month. More specific deadlines, he believes, are less likely to be met and cause unnecessary concerns to the customer and development team.
Project teams end up creating their own problems, he says, trying to put a specific delivery date on an item before they really know how difficult it is. “At some point, someone’s going to have to guess. If you’re asked to estimate something you’ve not done before, how else can you do it?”
However, milestones should be specific and easily measured, he says. “If it’s not in the build, it’s not finished.”
Similarly, De Luca says Gantt charts with their tight, interlocking milestones are responsible for “compound errors”. He prefers a centralised visual representation of the project status that allows for accountability. A weekly summary is produced showing the number of features completed, in progress, inactive or behind schedule. An ongoing graphical summary called “parking lots” shows the status of each feature set so the customer and project team can see progress at a glance.
He believes design and code inspection is more effective than testing, but warns there’s a limit to how much inspection can be done at one time. After two hours “the brain is mush”, he says.
Agile methods “expose people and interaction issues as first-class problems”, allowing a project to be more accurately tracked, De Luca says. However, the project itself is the only accurate measure of how difficult a feature is to implement. “There is such a thing as a bad plan or a bad schedule. They’re pretty easy to identify: it’s when you miss the date,” he says.
“Work that’s not performed according to a plan invalidates that plan, even if the workers are utterly incompetent — because we were supposed to know that. You can’t turn around and say the people are no good. That should have been in the plan.”
Everybody with input into a schedule has to accept responsibility, he says, including the marketing manager who “throws a tantrum” and insists on a six-month schedule if the project then takes a year.
About 80 people attended De Luca’s talk in Auckland, and about 75 registered in Wellington.