With the moden approach of development that leverage a lot of complexities to some development ecosystems like Drupal, the organizations need to optimize a lot the time and resources giving a prompt answer to the clients expectations about complex functionality that more than ever is dispersed in a lot of applications that are taked as a reference for many product managers. How to say not to a feature request that is contained in a module ready to download and install? Drupal works in easy way and have thousands of features ready to use and the client expecations raise for the people that every day is living internet and modern web applications which provide very interesting tools that make the life easy for the web users.

To react in agile manner the Drupal service companies need a high level of organization and expertise to prepare good project planning and budget estimations to doesn't lost profit while try to satisfy all the complex request from the product managers from clients. The reason for this phenomenon is easy: Drupal is agile if you ara capable to understand all the available APIS that are provided from Drupal core and from most popular (and non popular but needed) contrib modules and have that capacity takes a lot of time of investigation, experimentation and a big learning curve. The truth is that only the service companies that are supported by experimented Drupal team are able to get sucessful projects that satisfy the most exigent clients in a very short and aggresive deadlines.

Unfortunately, the most talented teams are scarce and busy doing sucessful projects. Then, how the service companies that are starting with Drupal ecosystem could reach a good performance? The answer is easy. Build a good infraestructure tools that protect your company from lost time and profits and detect quickly the bottlenecks. Here raise the tool Open Atrium, a very powerful tool that could very well any service company that need to stablish a strict process of organization in the conceptualization, design, testing and development of a project.

Open Atrium is very customizable tool and could adapt to many methodologies but I highlight some best practices:

• Once a project is sell and the concept is approved by the client, dump all the requirements document to Cases.
• Use the Notebook functionality to track all the dependent documents and them evolutions as requirement documents, project presentation, information architecture, markups, etc. Create a good skeleton easy to understand and predict for any member of the corporation that want to get into a project. This will reduce the adaptation cost of new member into the team.
• Document the application architecture explaining the most important modules, content types, taxonomies, dependencies, etc. to get a bird eye from the project.
• Use the Blog to describe the day to day progress or barriers to get all the team informed with a short resume for the Project manager. You also can use it to organize some Sprint lists of cases that will be achieved in some interation.
• Get some operations manager to follow each project getting reports with some interesting indicators as incomplete Sprints, desviations from estimations and real spend time for each Case, number of comments for Cases, number of commits for Cases, untouched Cases for more than 3 weeks (or more), etc. This kind of reports could help a lot in a prompt detection of troubles.

In the next article i will describe some extra modules that could be intergrate very easy with Open Atrium to get more information in the Cases as commits, estimations, timing or how to prepare an easy Sprints generation via a Blog post.