Keeping a site production schedule can be a challenge. There are many factors that go into creating a production schedule and many are not unique to open source. When you add the unpredictability and lack of control often experienced with open source, your ability to predict a schedule and deliver a fixed set of features become a juggling act. Add to the mix potential learning curves and you can have a challenge on your hands if you assume anything is possible and promise it.

Below are some insights into scheduling a Drupal project.

Module Availability

Because open source systems are created and updated on a volunteer basis, it is hard to predict when a module will be available for use by the open source community. If you need some influence over when a feature is available, you have some options.

In-house Development

Develop, test, and maintain the modules you need. There are going to be times when this is not worth the effort in the long run. For example, if during site production you decide you need a feature that is not available from the community. Your developers say they can create the feature for you in a custom module. You pay for the service and are very happy.

Then the time comes to update Drupal's core or one of its modules and your custom module breaks. Something in the module was coded to accommodate how the core or contributed modules used to work before the update. Do you hire your developer to come back and update your custom module? Was the feature worth this expense in the long run? A good old-fashion Cost Benefit Analysis will help with this decision process.

Collaborative Development

If the function you need is already being developed by someone in the community, consider working with the developer to complete the module. Maybe you are a coder or you are willing to hirer a coder to help with the community module.

Working collaboratively helps reduce duplication and helps the community get a new or updated module in a timely manner. Then, over time, as the core modules and contributed modules get updated, you are more likely to learn about updates that are needed and are more likely to have a solution in a timely manner - as long as you continue to collaborate.

Pay for Development

One form of "collaboration" is to pay the developer/maintainer of a community module to either speed up the development or make an enhancement.

Remember, Drupal modules are often built and contributed to the community on a volunteer basis. Sometimes a monetary incentive can help move a project up the developer's to-do list. You get what you need, the community gets an update, and the developer gets compensated.

Requirements Adjustments

One way to stay on schedule is to modify the requirements. If you are the developer, this can be a delicate negotiation with your client but if you explain upfront how Drupal and its contributed module development works, a conversation to adjust expectations shouldn't come as too much of a surprise - assuming you didn't make any promises without doing your homework.

So the decision might be to change or delete a requirement until the feature is available (not the best option but at times realistic).

Other Schedule Challenges

The following challenges are not unique to open source systems but they do exist in the Drupal world so they should be mentioned.

Learning Curve

Each content management system (open source or not) is different and some will appear to be easier to use than others. Some say Drupal has a steep learning curve if you do not have the appropriate web development background. Before you become too committed to using Drupal you can investigate other options. Bottom line, choose the CMS that meets your requirements.

If the learning curve for the CMS that you need is steep (given your experience), allow time in your schedule to come up to speed. Just because a CMS is quick and easy to install and configure, that doesn't mean the CMS will actually meet your requirements in the long run. This in turn means you might have to start over again and that can be a huge schedule impact, not to mention cost impact as well.

Productivity

Applications like Drupal can make it easy to combine production phases. For example, if you want a site whose features are readily available in Drupal, your development phase might move along quickly (as little as a few hours) because everything is "out-of-the-box."

There are production methods (e.g., RAD, Agile, Spiral) that are known to speed up production as along as you know your requirements. Whatever method you choose, take time to analyze your needs and document your requirements. These two phases are critical success factors in whether your site works the way you want.

Duration

If you have little or no experience estimating schedules, duration is something most forget or overlook. The challenge comes when the hours of effort are not available in one sitting. Your time, your team’s time, and your contractor’s availability are factors in determining the duration of your project. In other words, you might need 40 hours of work to be done but those 40 hours could get spent over a course of months. This issue is not unique to projects using open source but it can be magnified if you are working with Drupal community volunteers. Because volunteers don't work on a schedule, you might need to wait a while before getting the feature you need or even get a bid from a module developer.

Conclusion

Remember that you are working with a community of volunteers when it comes Drupal's core and all it modules. If you need or want predictability, you might need to revert to more traditional development methods - code it yourself or hirer a developer.

You could use Drupal and its modules as a spring board to writing your code but if you choose to hack core or any other module to get what you want done quickly, you have in essence disconnected your site from the community. The community can't help you maintain it.