How do you make your church's website? I am not talking about tools, but rather processes. There are several website development methodologies you can use. In this article I am explaining the three most popular methods. This includes discussing their characteristics as well as their pros, and cons. Hopefully this will educate you on what exists and what will best work at your church.
No website creation/update process at all quite common at churches. This chaos is where many church websites are born and updated. There are no real characteristics other than there is no process. Or the process is so ill-defined or ignored it might as well not exist.
There are few pros to having no method. Yet one positive aspect is that projects have no initial overhead. When you do not have to stop for directions, it is easy to get a head start. However the obvious problem is what happens if you go in the wrong direction. So unless you have a clear and obvious goal, stop to plan and track your projects.
Projects have no prioritization other than what leadership deems important at this moment. This can lead to rapidly shifting priorities that result in accomplishing few goals. Steps are not repeatable as no documentation exists. This is problematic when an update goes well and you cannot improve. It also means you cannot avoid making the same mistakes of a troublesome update. In addition, new team members have a steep learning curve and no documents to get them started.
Traditional software development followed a waterfall methodology. You first determine your software's scope and outline every feature. You then design the interface and data structures. Next was actual development. Finally you test and submit the software for acceptability testing. Designs and plans are thorough and precisely documented, but follow a rigid and lengthy schedule.
This method is extremely thorough, with plenty of documentation for repeatable success. You can easily bring in new team members, as everything is laid out from beginning to end. Plus at any moment you can report on your progress to management and committees.
The amount of overhead to document everything from beginning to end is tremendous. You will spend days if not weeks defining projects. Larger projects also have higher risk as a flaw early in the project. If these occur, they will cause massive amounts of re-work during testing.
Like waterfall, set a large objective. Instead of documenting every detail, break off a small piece of work. Perform the same cycle of design, develop, and test; just note that it is a much shorter cycle. These small chunks of work, called sprints, last about two weeks. After each sprint, your review the work and plan the next chunk. When you finish the larger project, conduct a final review and release.
This methodology reduces risk by performing shorter iterations. If you make a mistake, you lose two weeks, not two months. An added bonus is there is less up-front documentation. You also see results seen more quickly. Lastly, this method encourages your designers to meet regularly with developers. This promotes collaboration and results in fewer communication errors.
This is a newer process and many experienced developers are less familiar with it. Plus many traditional project managers have not used this methodology before. There are books and classes on agile, but experience is the best teacher.
This article scratches just the surface of website development methodologies. There is much more to read and consume at your local book store. You may also think I sound very "pro agile". While I do like many aspects of agile, there are places for the others. Having no process is helpful when you first creating a website and want to get the basics published as soon as possible. Waterfall is useful when the project is fairly small. Plus you can use a smaller project to ease into an agile method. Regardless, conduct your own research and see how you can use these tools to produce better website results.
Image courtesy of Caffe