People can be messy: they cheat, they lie, they’re lazy. The newest iteration of Canadian project management newcomer Devshop is striving to take into account the human frailties that can slow down and muck up software development and harness them for a more streamlined process.
The Ottawa-based Devshop has its roots in the scheduling breed of project management, according to owner Craig Fitzpatrick, who released Version 2 of the application recently after an initial launch last spring. After working in development at several software firms, he grew sick of several things—late projects, and staid project management and scheduling software. “Getting software development projects in on time can be a rare thing, so, in actually achieving that, there’s a lot of money to be made,” he said.
More in ComputerWorld Canada
A lot of scheduling software leaves something to be desired, said Fitzpatrick. “It often allows you to draw out any schedule you want, which is often unrealistic because you don’t build in things along the way,” he said. Fitzpatrick also found that the programs were often lacking
flexible long-term metrics that would grow with the project.
Factors like not knowing how long something will actually take to build and people switching hats during a project can louse up a project development cycle.
According to the Tamworth, England-based IT consultant Mike Sutton, “Your release cycle must be as accurate as you can make it, not some pie-in-the-sky number that you made up during lunch. Before you announce it, test it out. There is nothing worse for a failing release process than more unrealistic dates.”
He cited the example of a major U.K. telecommunications provider’s important supplier switch implementation, which required reengineering of the billing and account management systems in three months. “We started out by suggesting a weekly cycle. That plan proved unfeasible; the client's database environment could not be refreshed quickly enough,” said Sutton. “Then we tried two-week cycles. There were no immediate objections from the participants, but it failed the first two times! In the end, two weeks was an achievable cycle, once we overcame some environment turnaround bottlenecks and automated some of the tests.
"Finally we established a cycle whereby, every two weeks, production-ready code from the engineering team was put into system test. Then two weeks later, we released that code into production. Your release cycle is not about when your customer wants the release. It's about when you can deliver it to the desired level of quality.”
Fitzpatrick wanted to make an application that accounted for human messiness. The Web-based Devshop takes into account these foibles…like, for instance, distractions. Developers can often get pulled away to work on other projects, said Fitzpatrick. Whereas before this time was informally added to the project span, now, he said, users can input these absences into the application for future reference. During the next development cycle, a manager would be able to see that that particularly user is often called away, and their involvement might thus extend the development cycle by a certain amount.
(This information is easily accessible via user profiles. There, individual metrics are listed, allowing teams to check in on what people are working on, and their track record within the development projects of late. )
The application has to learn somehow, so users can “score” several metrics of the projects, including time, requirements, and design. This way, they can log time spent on each part of the development cycle, and score how the project is coming along within the original projections, so the requirements don’t have to change. Instead, the team will have a more realistic view of how long a similar development project might take next time.
Project sponsors often latch on to the initial estimates project managers propose for the schedule and cost of a project. And because project sponsors don't understand project complexity and other factors influencing cost and timeline when requirements change, they may see the project as a failure if costs increased, even if the changes improved the value delivered to the business. Unfortunately, business executives' lack of understanding about project management influences their perception of IT project success and failure.
This functionality could be increasingly important as more and more projects get muddled along the way due to development complexity . "Project requirements change for a variety of reasons, and schedules and budgets change during the lifetime of the project based on better information as to effort, complexity and interdependencies," according to “Debunking IT Project Failure Myths,” a Forrester Research report published last month. "This would not be an issue except that project sponsors judge project success in terms of schedule-budget-meet requirements," said report author Lewis Cardin.
With Devshop’s accounting for the human factor could become a more popular practice in the project management space as time goes on, if Forrester has anything to do about it. Cardin recommends project management teams establishing best practice for developing plans for projects that involve "significant unknowns." Such established best practices would help in setting business sponsors' expectations for reasonable project performance and reasonable actions for a project manager to take under different conditions.
Devshop—and its progeny—could more clearly articulate to project sponsors the most important parts of the project, such as how they come up with estimates for a project's cost, schedule and the resources it will require, how those estimates are based on certain business conditions, and how changes to those business conditions can impact the cost of and timeline for the project.
And, according to the Forrester Report, one of the main benefits of this type of project management practice? Keeping the heat off the IT department and project managers in the future: business executives' lack of understanding about project management can influence their perception of IT project success and failure.
--With files from IDG News Service