So daylight-saving time has just begun in various parts of the world, and that means many of us — including the normally razor-sharp team here at LinuxInsider — may be reeling a little bit.
An hour’s sleep is a big deal, so “springing ahead” — which always sounds so chipper and perky — can actually make the ensuing days feel long and tough. Which brings us to the topic of today’s column: Tough projects.
We’re not talking just about projects that require effort, or that take some time to get done. We’re talking the ones that cause that heavy feeling in the pit of your stomach, that cause early graying … the ones that make you wish you’d taken your mother’s advice and gone to med school instead.
These are the toughest projects, and they often represent our biggest challenges. Unfortunately, we don’t always recognize them in advance. Luckily, help is at hand.
Five ‘Tough’ Factors
Inter-Sections blogger Daniel Tenner wrote a post on this topic a few weeks ago with a set of guidelines to help developers and managers assess — ahead of time — how tough a project is going to be.
Essentially, Tenner broke it down into five types of risk that may be involved with the project:
- Technical risk (number of features)
- Market risk (user pickiness)
- Technical risk (complexity of features)
- Market risk (strength of the competition)
- Technical risk (integration risk)
“If you’re building a sprawling application which does ten thousand things, is aimed at almost everyone, retrieves and reprocesses data from thirty external systems and has strong, well established competitors (the My Google homepage would qualify), your project is tough,” Tenner concluded.
“On the other hand, if you’re building an application which has just one feature (e.g. generate random passwords), will be imposed on your five thousand internal corporate users and will require use of cut and paste to work with existing apps, your project is not tough,” he wrote.
Tenner’s topic is a critically important one and his advice is sage. So we couldn’t resist asking around to see what others might have to add.
What Is Tough?
“I think sometimes people get too wrapped around the axle about how tough something is,” Slashdot blogger yagu told LinuxInsider. “I’ve found in 25 years of design and development that some of the most complex projects were the least tough and vice versa.”
Assuming the business case is already made — a vitally important step, yagu notes — the critical needs for a successful project include “finding clients who know (really know!) what they want; finding technical team members who know how to do it; and putting them in a room together until it’s done.”
An oversimplification? Not really, yagu says.
“I worked on a project where I knew I could deliver the technology if I could handpick one or two team members and work with the clients directly,” he recalls. “My senior management agreed and flew me and my two team members to Phoenix, Ariz., where we lived with our clients in their workplace for a month. We had a working prototype of their new application in two days! The final result is now a strategic application for the company.
“This was a high-risk, very complex, and very difficult application to write,” he adds. “But with the right people (people who know what they want), and people who know how to create it, it wasn’t tough.”
Maybe the tough part is assembling a team that knows how to pick people who know what they want, and how to pick a technical team that knows how to create the technology, yagu suggested. “But, if you do get that combination, it’s amazing how ‘tough’ becomes easy.”
‘More Tableware Than Rules’
One of the biggest challenges is getting the problem defined correctly, agreed Roger Kay, president of Endpoint Technologies.
“If the system designer sitting down with the person spelling out the requirements can’t come up with a description of what the problem is, you know you’ve got a tough one,” he explained.
Also indicative of trouble are a very large number of inputs and outputs, he said — “just mapping it out will take five years” — and “more tableware than rules,” meaning the exceptions outnumber the cases covered by the rules.
Then What?
So what do you do if you do get stuck with a truly tough project?
Tenner’s post promised a forthcoming one on that topic, so LinuxInsider asked if we could get a little sneak preview.
“The main thrust of the next post is that you need a specific kind of programmer to work on that kind of project,” Tenner told LinuxInsider.
“Essentially, it always comes down to people,” he explained. “Either the developers won’t be able to deliver what’s needed at all (rare); the developers can deliver it, but not fast enough (very common); or ‘what’s needed’ changes too fast for the developers to cope (quite common on projects building something new and undefined).”
Such projects require a team representing the cream of the crop, Tenner concluded.
How to find those solid-gold contributors? Start by reading Tenner’s archived post and our column on that topic. Good luck!
Loading ...
