The decision to implement a tool to automate workflow, project management and time reporting is one most creative departments face. In fact, if you don't have some tool in place you are likely behind the curve in operating best practices. Determining what tool to use can be daunting. There are numerous "off-the-shelf" packages available, as well as the consideration of custom application development. With all the packaged solutions available, why would one ever consider a custom tool? In my experience, building provides a creative leader and her team with significant advantages.

Marketing and creative services groups have unique workflow and project management challenges. To complicate things further, your company and work processes are also unique. You do not have to settle for a workflow tool that was developed for the industry in general or worse yet, for "project management" in general. You can develop a solution for the way you and your team work. It is possible to create a workflow tool to fit your specific needs and budget without compromising your process or business objectives. Building a tool is well worth the investment.

Requirements--The benefits of a custom build are numerous. They start with requirements gathering. All too often when an off the shelf tool is considered, the requirements list is put together by determining which of the many features you want to implement and how you want to customize them for your company. When handed a list of requirements to choose from you are already giving the impression that you are more interested in the developer than in the end user. In this scenario, the need for requirements is dictated by the software.

A much more productive approach to requirements gathering is often taken when developing a custom tool. Rather than starting with what the tool offers, one starts with your work, running through projects and scenarios, how you do them, identifying the unique processes and challenges and reporting needs for each functional area. This approach renders logical requirements with the end user in mind. Not only are your requirements more on target, you have already moved a step closer to adoption of the tool by speaking in the user's language and making their needs top priority. Regardless of whether you build or buy, we at Cella Consulting would always recommend you take this approach.

Interface design--Let's face it: most creative folks not only like but also need an intuitive, user-friendly interface. Hands down, the best interface design for your needs is accomplished through a custom tool. You don't have to settle for the off-the-shelf solution or face costs to provide a custom interface. Your designer can create an elegant interface to meet your brand and user needs for your custom application.

Features--Packages typically offer a broad range of features--often more than needed. Depending on the tool they may be industry specific or much broader. In my experience you are often left with more "stuff" than needed, which can lead to confusion--especially when working with intuitive users. Compare that to putting in the features you need, the way you need them, making it easy for your team to use the tool. Your tool can be very robust with many features; the difference is that they are the features and functions of benefit to you.

Workflow--Even though there are a lot of features, some packaged tools seem to fall short when it comes to workflow. This is where your organization will have some uniqueness based on industry and business objectives that you will not want to compromise. You will want flexibility built-in. In a custom tool you have the ability to create the workflow and automation that is exactly right for your company. You'll need to review many packaged tools to find one that offers a workflow automation that will fulfill your requirements or you may need to compromise in this area resulting in a change in the way you work. This is not always for the better and can result in the dreaded work-a-rounds resulting in partial tool adoption and inaccurate data.

Language--Have you ever been in the situation where you have been told, "Sure, we can change the language to suit your internal terminology needs." You implement a tool with your company terminology and when an upgrade comes along the terminology reverts to the package language. This isn't a concern in custom development. You should recognize how often your company institutes change so the tool you develop is flexible enough to adapt.

Tool implementation and adoption--In designing a custom workflow application, it is necessary to involve users. A best practice is to hear from each functional user group and to also select a functional "champion" for each group. The champions should be folks who are well respected by their peers and technologically savvy. These are not managers. The champions will be your early adopters and will help their peers adopt and use the tool. Because these folks are well respected, their word and opinion will be valued. Having them active in the development of the tool will help ensure success.

This should also happen with a packaged tool but because so much development is already done, the users are a little more distanced. Depending on the complexity of the packaged tool, the training and adoption can take months. It is often less intuitive than a custom design. A custom tool has a near immediate adoption timeframe not only because the users have been involved in the development but also the tool itself more closely represents their processes and problem solving.

We all know the data collected in a tool is only as good as what is input. Whatever tool you use, it is ultra important that the tool be accepted and used by all to obtain good accurate data and reporting. Consider this when selecting a tool. How easily will it be put into use?

There is no doubt that there is a place for both off-the-shelf and custom application development. We learn more as products are implemented and learning shared. It is most important to implement a tool that is right for your individual organization. Know your objectives before you begin tool selection and develop a tool that meets your needs including budget, timeframe and functionality. Are you trying to reduce redundancy? Automate aspects of the work? Gather data for metrics? Increase speed to market? Whatever your objectives, state them clearly up front and agree to what success looks like. Keep your objectives in mind throughout development and test against them as you make decisions to ensure success. Don't discount a custom build without some exploration. It just may be the solution you are looking for.