|
August 18, 2002 Newsletter.
Subscribe now.
|
If you've been in the technology business for a while, you've heard things like:
"The software project is slipping again. So what's new, software projects always slip!"
"The software team says they'll be done in October, so maybe we'll actually see it in January or February."
The bad news is, the real costs of schedule slips can be enormous. And there's even more bad news: wireless software projects have some special challenges. Many enterprises, burned and frustrated by their inability to control these projects, now try to fit "canned" solutions into their IT systems.
The good news is, with a proper handling of the special characteristics of wireless software projects, solid, software can consistently be delivered quickly and on schedule. These projects can deliver solutions that are more maintainable, extensible, and highly optimized for the enterprises' current and future needs.
|
Unfortunately, the real costs of schedule slips go way beyond the cost of resources for the development team, and repeated slips usually start a chain reaction that can disrupt an entire organization:
Loss of competitive advantage. If the software project is part of a company product, delays in reaching the market can be damaging or even fatal to that product and company. Even if it's an internal project, the realization of benefits, which should far exceed the cost of development (else why do it?), are delayed.
Delays on other projects. When a project is behind schedule, other projects that should be getting attention are also affected.
Loss of continuity. If a project slips enough, inevitably development team members will be interrupted and "borrowed" to work on other projects or put out other fires. There's a significant loss of efficiency when developers jump back and forth between projects.
Demoralized development team. Noone likes working on a project that's behind schedule and under pressure. Technical people thrive on doing good work and getting some recognition for it, and there's not much chance of that when a project is late and has a cloud over it.
Undermined credibility of project advocates. Whoever "sold" the project to upper management is going to have a credibility problem next time. This is not a great career move.
Squeezed alpha and beta testing. When the development phase of a project gets behind, typically the first thing to get squeezed is proper alpha and beta testing. This is exceedingly dangerous, especially for wireless software projects.
Disruption of non-development resources. Organizations that are responsible for marketing, documentation, training, procurement, etc. are delayed and disrupted, affecting their abilities to efficiently schedule and support other projects.
Second-guessing on schedules. In an organization in which "schedule credibility" is low, second-guessing on "real schedules" begins between departments, making any kind of high-level forecasting and planning a frustrating exercise in futility.
Obsolete solutions. For a variety of mysterious reasons both inside and outside of an organization, the world tends to change and render late projects obsolete before they are finished.
There are several special challenges of wireless software projects:
User Interface. Unlike applications which run on a desktop, wireless applications are developed for devices which may not be very familiar to the intended users, especially for data applications. Getting the user-interface right is absolutely critical to the success of a wireless project. Some extra concept and design cycles are needed early in the project, and some extra test cycles later in the project.
Device and network anomalies. Wireless devices and wireless networks don't always work exactly as advertised, especially in handling data, and sometimes they can even be moving targets. Even when industry-standard protocols are involved, each manufacturer or carrier will typically interpret them a little differently.
Immature development tools. The software tools that are used to develop wireless applications have come a long way in recent years, but are still far behind software tools for more established environments. In addition, documentation that may be used to scope a development project sometimes isn't accurate.
Lots of ink has been written on classic software development processes. These ideas apply to wireless projects as well, but here we focus the principles that most apply to the special characteristics of wireless software projects:
Use an appropriate development model. At Outr.Net, we refer to the "user experience", which includes the user interface plus they way information is delivered and accessed, and the way expectations are set with the user relative to communications and offline operation. It can't be emphasized strongly enough: getting the user experience right is critical to the success of a wireless software project. It also is a core part of requirements definition, so it's important to plan sufficient cycles for user prototyping and testing.
Identify the technical risk areas early. If there are any functions which haven't been previously characterized, on exactly the same revisions of the device and network, there is an area of schedule risk. Frequently 5% of the project causes 90% of the headaches. Some early testing and prototyping can isolate these problem areas and help identify alternative solutions or workarounds.
Get help from specialists. Engineers love to learn and reinvent, especially when they are assembled into software teams and IT departments, but it's extremely worthwhile to at least engage the advice of those who have been down the same trail before. They have already found the landmines the hard way, and you don't need to repeat that exercise.
Use existing modules. Existing software modules may be available by device manufacturers, network providers or other software developers to handle core functions like communications, local datastores and event handling. It is very worthwhile to take the time to seek these out, at the very least for reference.
Use an structured scoping process. Outr.Net has developed an scoping process for wireless projects - an example from a recent project can be downloaded here, with the names changed to "protect the innocent" (696K .doc file):
It's always a good idea to bounce the schedule estimates between two technical experts to allow them to challenge each other on risk issues and alternatives.
Trust the development estimate. If a structured estimation process has been used and challenged appropriately, and the schedule isn't acceptable, then it's time to look at the "other two legs of the triangle": features, and schedule. Usually some creative discussion on implementation options, or essential vs. deferred features, will result in a solution that everyone can live with.
Sometimes, even if everything was done well in the concept and design stages, the best experts get surprised by a problem. Therefore:
Don't give away "catch-up" time too early. Overtime should never be scheduled at the onset of the development phase.
Allow for "give and take". Occasionally the implementation of a specific feature may prove to be so cumbersome that it can throw the schedule or performance of an application off track. Be flexible and creative, even late in the game - sometimes the user experience can be enhanced with a much simpler solution.
Of course, eventually it all comes down to execution on the part of the developers and the project managers. There's no substitute for experience, good process and good execution.
To summarize, the bad news is the costs of schedule slips on software projects can be enormous, and wireless projects pose some special challenges. For these reasons many enterprises have opted for "canned" wireless solutions.
Unfortunately, they find some canned solutions to be expensive, inflexible, and marginally suited to the enterprises' specific requirements. After all, the developers of canned solutions will focus their resources on developing solutions that satisfy the "least common denominators" of all their current and prospective clients.
When done properly, custom wireless software projects can be delivered quickly and consistently on schedule. These can provide wireless solutions that are far more optimized for the enterprises' current and future needs. And because the enterprise participated in the design and has control of the source code, these solutions can be far more maintainable and extensible over the long run.
In a highly competitive market, this can be essential to controlling one's own destiny, and achieving and maintaining a competitive advantage.
Written by:
Kim Spitznagel
President
Outr.Net, Inc.
Comments on this newsletter? Please let us know.
I'd like to subscribe to the Outr.Net newsletter.
| 
