Success in designing and building a web site depends on communication and collaboration among team members. Everyone needs to understand the goals, perspectives, and approaches of the other team members. And these need to be decided on up front.
Communication is a special challenge because of the intangible nature of this work. The information architect must identify goals and content, keep them in mind, keep them visible, and keep everyone on track.
The biggest cause of failing projects is not defining the problem to solve.
If you don't know what your goal is you can't tell if you've reached it. And even a well-defined goal can be the wrong one, so it's important to question everything every step of the way.
Typical Problems and their Causes.
Software development of all kinds suffers from the same kinds of problems. You can lump all these together under poor planning.
It doesn't really matter who is managing. If a project isn't thought out then it can't be run well. If a project is not run well then it can't succeed. No amount of hard work can fix things.
Software development is one of the newest and hardest kinds of creative work, and not all of the rules have been worked out yet. This goes double for web sites, so it pays to be cautious.
Problems come from not knowing the rules, and from deciding to crack the whip louder, hoping that everyone is suddenly working faster and feeling happier. Well, it will force people into line, temporarily, out of fear, but that won't help anything. At all.
So, check these out:
- Have clear, documented goals.
- Know your requirements.
- Objectively assess.
- Attack risks.
- Devote resources to testing.
Here's the number one rule: If it isn't written down then it doesn't exist.
And if you don't think that's true then try to prove it. You can say one thing, then have someone disagree, and then where are you? If there's no proof, there's no proof, period.
Running on hearsay doesn't cut it anywhere, and surely not in business. Writing down your thoughts and passing them around is often enough to uncover huge gaps in your understanding. If not today, then tomorrow morning when everyone is taking a fresh look. If warts are there to be seen, someone will see them.
Ad hoc requirements management is another big issue. Same lack of planning.
Don't expect to shoot from the hip and hit your target. You have to know what your project requires and so does everyone else. Flying without a plan is at best a guess, which is a huge problem. Everyone has to work together with a clear mission or else you all get confused.
With no plans and no documentation you get inconsistent requirements, mismatches between requirements and design, and more mismatches between design and implementation. More points of failure. You need fewer ways to fail, not more.
If you keep getting it wrong you'll have even more plagues and pestilences. Subjective assessment of project status, for example, rather than knowing for sure. It's a lot like having a hunch about your checking account balance, expecting everything to be just fine because you want it to.
If you start confused you probably haven't assessed the risks to your project. Ignore risk and it will blindside you. Not attacking risk means it is free to attack you. At best you end up with a brittle architecture. One that is too complex, too big, too cumbersome, too weird.
No matter who you have on testing (you have a dedicated testing staff, right?), your testing will be poor. Even if it's automated (you have it automated, right?).
On top of all this, if you do manage to get something limping along you will then propagate changes in an uncontrolled way, so you be piling new messes onto the old ones. A big, tangled mega-mess is what you'll get. One that can't be either fixed or added to any more. And then what?
There are some best practices though. As with a lot of things, they may be hard from time to time, but they're pretty simple.
- Develop iteratively.
- Manage requirements.
- Use patterns and templates.
- Visually model systems.
- Control changes.
- Continuously verify.
Manage requirements. Sounds simple. What is it? It means that you have to keep learning what you need as you go along. It's like having a grocery list and throwing a few more things into the cart when you realize you left them off the list.
Use patterns and templates. Know enough about what's been done before, and how it's been done, so you can work with a proven solution and more or less fill in the blanks as you go along.
Visually model systems. A few sketches can do it. You can sometimes answer a question with a picture in less time than it takes to ask. If it's the right picture.
Control changes. Developing iteratively gives you flexibility to add and remove things, but knowing your requirements keeps you from getting carried away. You have to know which road to be on, and then stay on it.
So you also continuously verify progress, continuously reassess your goals, and continuously verify quality. In other words don't assume that going through the motions is enough. You keep looking around, checking the compass, making sure all the wheels are still attached. Quit paying attention at your peril.
Get Used to an Iterative Approach.
Every project, and every step of every project has a beginning, a middle, and an end. No one says you can't pass by them several times before pulling into the garage.
Begin, then plan. Gather requirements. Manage the environment. Analyze, and then design. Implement, and then deploy. Test everything, every step of way, including requirements, analysis, and design, not just finished work. Test yourself. Test your customers. Everything.
Then repeat until done.
The more you do something the better you get. The more you do something the more familiar it gets. The more familiar things get the easier they are to understand. And the more likely it is that you find the warts and bugs and scabs when you can still do something about them.
Iterate gladly. It's good for you.
Iterate because iteration keeps you from failing, and from losing your job. Or your business.
Iterate because it's faster, because you never have to stop, and back up, and undo a whole bunch of work, and then do it all over while hoping for the best, while sweating blood.
Iterate because it works. If somewhere you make the wrong assumption, you won't be going too far before pausing at the next checkpoint.
This is creative work, not manufacturing, not floor sweeping. It's all too easy to miss critical factors. Human factors. Business factors. Technical factors. You name it. Especially when moving from the familiar into the unfamiliar. Take small steps and watch for tigers in the trees.
This iterative approach will help you. The single big leap (the traditional "waterfall" approach) will bite you. Hard. Remember, the point at which you know the most is at the end of the project, not up front. So plan on finishing small stages several times, and not on laying it all on the line once only.
Some Wrong Assumptions in the Waterfall Approach.
Assumption 1: Requirements are frozen. Nope.
Users, visitors, and business conditions change. The most fundamental business problems change over time, and sometimes that time is a few days or a couple of weeks.
Assumption 2: Technology never changes. No, seriously. It does.
Assumption 3: Markets don't change. What did we just say about business conditions?
Assumption 4: The level of detail in your requirements is always perfect. If you assume that they're right, and chisel them into stone, and only find out way late that you are way wrong, well, good luck there.
Assumption 5: After you've gone over the cliff is a good time to change your plans. How are those frozen requirements working for you then? Still OK?
Assumption 6: The design is right on paper, so it's right, period, isn't it? Heh.
Assumption 7: Risks can be put off or ignored. In other words, if you assume that you can leave the hard stuff until later, or maybe sort of ignore it and it will go away on its own, well...
Assumption 8: Time scales can be expanded with no problems. Sure. Just expanded and expanded and expanded, and then a miracle happens. Works every time.
Assumption 9: Reams of paper documents on shelves are really valuable. This is fine if you are producing documents only to decorate shelves. Documents like to breathe, and move around, and interact with people, so why not use a wiki? Or have quick, informal meetings every couple of hours or so?
Assumption 10: You'll get the first version completed, something that works well enough for now, and then when you have time and money and staff you'll go back and do it right. You'll add all those things that should have been there at the start. If you're still around. If anyone can remember what it was that somebody mentioned once upon a time.
If you ever get that time and money and can recover the creativity for it. Or maybe not. If the company is no longer business.
On the other hand.
With an iterative approach:
- You mitigate risks earlier on. Nothing like swatting that mosquito before it bites.
- Change becomes manageable. Because there is only a tiny bit of change from one iteration to the next.
- You get more reuse because you pass by things more often and start to see where you can use one piece of code or one template in half a dozen places instead of inventing it over and over again. Or you invent a pattern to apply in similar cases.
- Everyone learns along the way, because you have a team approach and the whole team watches the scenery roll by again and again. And so quality gets better. Inevitably.