To Build a Church Web Site: Plan the Project

This entry is part of a series on building church websites. Check out the first post.

Require Project Sponsorship and Involved Stakeholders
Having fought through a number of IT projects in the past without executive sponsorship and involved stakeholders, I don’t think I would do it again. It isn’t fair to the team of people who are working so hard to get the site built. If the project isn’t important enough to the organization that an executive or Elder needs to oversee it, then the web project has a low opportunity for success and the outcome will be poor. When we say “executive sponsorship”, we aren’t just saying a dictum or decree is handed down that all staff will cooperate so the site gets built. We are saying that a) this individual is accountable to others for the projects success, b) he/she is engaged in every phase, and c) the person is clearing roadblocks for the web team that they can’t clear themselves.

Stakeholders are those individuals who have a stake in the success of the project. I define this as being either an internal person who has needs to be met, or a resource who is responsible for project deliverables. In the model we use at my church, stakeholders typically have needs and have deliverables. This is because we have chosen to decentralize much of the content management tasks beyond the base of the site (top 150 pages or so). It is important that stakeholders stay engaged at various levels throughout every phase. For instance, if your target audience are non-members, then you might change ministry names like “Junction 56″ to something like “Preteens” for navigation purposes. You will need their buy-in prior to doing this. If they understand the purpose for the site and the target audience, it is a shorter conversation to convince them that using a different name will actually get them where they want to go. Also, when stakeholders are engaged with other stakeholders, they will share best practices and develop new ideas for their ministry areas on the site.

Choose Vendor Partners Wisely
A few years ago, the web-master was pronounced dead. That is to say that no single person can deliver and maintain a sizeable web site on their own. The reality for a big church is that unless they have an unlimited budget and a lot of sites, they are probably going to need to outsource portions of their project to vendors. It may be writing, information architecture consulting, graphics design, front end coding, content management integration, hosting, photography, or flash video, but something will need to be outsourced. Our approach was to outsource everything but the writing and photography. However, we did not hire an agency to do the whole site for us. Typically this is more expensive and the church gives up a lot of the control of the project that helps to make the site their own. Also, you have to own the site after the launch, so having someone on staff that is central to the sites construction is the best way to go in my opinion. The project manager role is one you want as an internal competency if you can acquire and support it.

So, we augmented our staff with the talent we did not have in-house. We literally cherry-picked the talent from a network of folks we have built over time. I will talk more about the outsourced work in future posts, so for now, here are a few things to remember when choosing vendor partners:

  1. Make sure they are comfortable with your project management process, including time reporting, to-do tracking, communication and discussion, project management software, etc.
  2. Do business with those willing to put an agreement in writing. I don’t trust companies with long contracts and out clauses. It makes me feel they don’t have my best interests at heart. You should still have something in writing with every vendor, no matter the scope of their involvement. Make sure the terms are fair for both parties and various scenarios are laid out if the project runs long.
  3. Find a vendor that will bill you straight time based on an hourly rate and be meticulous with their time reporting. I typically ask them to bill in 15 minute increments so I don’t get charged for a full hour every time something small comes up or we have a brief conversation. Agree on a cap for the work effort. This works a bit like a fixed bid approach, but you typically give the vendor as much as a 10% ceiling so they have some wiggle room. You want them to be successful too.
  4. Check references and do you own investigative work. Don’t trust one reference. Anyone can crank out one great project. Look at their portfolio and contact the companies they have served in the past but are not on their references list. Also, Google their company founders name and find comments they have made in forums online. You can tell a lot about a person by reading their comments elsewhere.
    Most importantly, make sure they have a heart for ministry. They don’t have to be Christian, per se … but they need to feel like their work is contributing to something more meaningful than a regular project. This will get them going on that extra mile toward excellence on your project.

Use Agile Project Management
While there are numerous methodologies for project management, I believe the best approach when building a church web site is an agile one. An agile method fits the way churches work. Ministries typically lack the kind of command and control environments (atleast the healthy ones lack it) that older methodologies were designed for. Also, church staff cultures are typically more relaxed and grace-filled than other work environments. So, staff don’t observe deadlines in the same manner as other companies do. If you have ever talked to an interactive agency that works with churches, they can tell you nightmare stories of delays in the order of months and years. Note that sandbagging each milestone doesn’t exactly work either, because if people know that they can let one milestone slip a little, they will. Remember also that Gannt charts aren’t useful for most people on a church staff. What is needed is a way to encourage people to meet their deadlines without the project manager having to play the heavy and use the big hammer of escalating to the participants boss.

Some things that knowledge workers in churches desire are respect and to be found a good steward of the responsibility they are entrusted with. So, using an agile method with frequent, open communication with all parties creates an accountability scenario that isn’t about the project manager not getting his/her stuff. We opened up the process by having constant, open communication that everyone could see at any point. The accountability was with the group and not the project manager at that point. People delivered for the right reasons and on time.

Establish Communicaton Channels
The tool we used for managing the open communication channel was Basecamp by 37signals. We subscribe to the $50 a month plan so we can break things out into multiple projects where necessary and have as much file upload space as we would ever need. Basecamp provides a virtual space for following messages with associated comments, tracking to-dos as a whole and per person within to-do lists, watching milestones, uploading files for sharing or comment, time tracking, and writing collaborative documentation. It was a life-saver on this project. This web-based project management tool allowed the project to continue when I was out sick two days and at a conference for two days. When someone missed a milestone, it was listed in red for everyone to see. As people finished certain milestones or difficult tasks that others were relying on, they would post a message within Basecamp stating what had been completed and in what way. This allowed dependencies to be seen by everyone all the time. This ever-present communication reassured everyone the project was moving forward. It also implied that others were waiting on you to pull your weight. The relationship between what a stakeholder owned and someone elses deliverable was constantly in view. This created a healthy peer pressure that took personalities and preferences out of the mix.

List and Track To-dos and Milestones in One Place
Basecamp is just one of a number of web-based tools you can use to manage a project in an agile way. Most of them allow you to track your to-dos and milestones in one place in plain view of everyone. Failures to deliver can be seen by everyone. The responsible party owns the ut-oh, rather than the project manager. Each to-do list on our project was associated with a single milestone (hint: name milestones the same as to-do lists). Initially each to-do/task was entered by me. Each to-do is assigned to a person in the system, and their name is seen beside each item listed. Basecamp allows anyone to create tasks for anyone else, so this makes it simple when someone hits a road-block with a dependency. They simply create a to-do within the appropriate list for what they need. Since both our content management system guru and our front end coding guru were outsourced, they could create to-dos for one another without my having to be in the way. This shortened our time-frame for design integration to less than two weeks.

Be Ever Present Most of the Time
In addition to Basecamp, there was one other tool that was instrumental for the technical professionals engaged on our project. Skype is more than instant messages. It’s instant messaging with history, searchability, status/presence, file sending, group chat, and link passing. Literally hundreds of non-voice conversations were done on Skype. Quick questions, points of clarification which didn’t justify a Basecamp message, and brain storming were perfect for Skype. It is one of the best tools I have found for allowing people to collaborate without being distracted from the task they were in the process of doing. As the project manager, I was in as many as 4 overlapping conversations at one time. This helped people get the answers they needed quickly. If someone needed clarity on a to-do, they pinged me with a simple question. Normally I could hammer out a few lines of text to get them an answer, without all the formalities that a phone call would have required. Other than a pleasant “good morning” and a “good night”, we had permission with one another to be direct and state what we needed in a matter of fact tone. With the five technical professionals engaged at points in this project, it worked flawlessly and without some of the bugs and limits of traditional IM services like MSN, Yahoo, and Jabber. Highly recommended for anyone who types fast and communicates well in text.

Know When to Meet Rather than Message
Even with using electronic means to communicate about the project, there were empasses which at times required a telephone or in-person meeting. Most of the time, these meetings were about philosophy or strategic decisions which simply couldn’t be hammered out easily in a Basecamp message thread or Skype chat. For instance, we had a devil of a time with content header use and design. We didn’t put enough time in to defining the requirements for the designer, and we paid for it with multiple meetings to decide how to nest content within headers. Also, we didn’t meet early enough on use of the WYSIWYG editor that sits within the Web Empowered Church CMS we use for our sites. We should have met earlier to talk about how it would be used when imputting content into the system. We burned precious time sending comments back and forth in the project management tool, rather than putting our internal team in a room to flesh out the issues. In general, if you have three or more opinions/perspectives on a topic that should be straight-forward, call a short and focused meeting to resolve the issue.

Have a Flexible Deadline, but NOT Too Flexible
The book Getting Real by 37Signals says to Fix Time and Budget, Flex Scope. To a certain degree, we followed this approach and fixed the deadline. We had to move back our launch date 20 days beyond what I had estimated 3 months earlier, but these 20 days were accounted for and acceptable. We flexed scope by not releasing our blog when our main site launched, and by making our Spanish translation and Google Sitemap individual phases for late May and June. The most important thing for churches to realize is that their site is not a one time event. The launch of a new site is just the beginning. It is where the really hard work begins. As such, release as early and as often as you can. Be willing to let the site go live if it is “great enough” and is better than what you already have out there. Be willing to spend the month after you big launch doing cleanup of all sorts of little things. That isn’t to say launch something that doesn’t work, but is to say that some things aren’t noticeable by the majority and will not prevent the functionality of the site.

This open approach assumes all parties a) genuinely want the project to succeed and b) are responsible people who take their ministry jobs seriously. This methodology will not work if the majority of the participants don’t have those two qualities about them, but then nothing would I guess. I am not able to flesh out all the philosophy and practices of this approach in this already long article. If you want to learn more, Getting Real and the Agile Manifesto Principles are the places to get started. Or, you could always hire me to consult with you on setting up the right project plan for your organization!

Posted in Design, Programming, Web Ministry, Writing

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>