Undeniable Facts About Development Projects

Our last blog post, Set Up Your Salesforce Development Projects for Success, started off as the introduction to our customer engagement on projects series. Here in part two, we will be discussing the high-level concepts of a traditional development project vs. a Salesforce project. In the post, we’ll go over

  • how standard projects tend to require large teams while Salesforce projects thrive with smaller teams
  • why Salesforce projects are a perfect fit for Agile methodologies
  • and how Salesforce allows the project to focus on business functionality and leave out the messy details of technology and infrastructure.

Salesforce makes it easy to see quick ROI, so let’s dive in and see how it makes this possible.

Large team vs small team

Standard software development projects are notorious at becoming complex once you dive into the details. This is especially true in enterprise environments where multiple layers of systems are stacked on top of each other and integrated.

Several teams have to be in place to support the network work infrastructure, the databases, the web servers, the application servers, risk management, business continuity, and security. What may start off as simple application can involve talking to the database administrators to discuss the type of data being housed and how to best structure the data and where it should live. Should there be a new database or bring the data into an existing? Even the network team could be involved.

Too many cooks in the kitchen

While it seems like the network is a commodity, once working in an enterprise environment, you will start finding yourself dealing with “punching” holes in the firewall to get to the data you need. If you add mobile access on top of that then it gets really messy.

All this creates a very large team where communication starts to become difficult and cross team dynamics and politics can get in the way of the project and slow down progress. Project teams can become bloated to 20+ members. This is far too complex to manage effectively without impact to the project. On the other hand Salesforce projects don’t require as much cross team development so team can be a lot smaller.

3 is the winning number

In all, here at 6 Street Technologies we have found that the perfect sized Salesforce development team is a team of three individuals. They usually consist of

  • a project manager/architect
  • a business analyst/administrator
  • a developer.

The project manager/architect is someone to lead the team and guide the over all vision and direction of the project.

Second, the business analyst/administrator has the responsibilities of gathering requirements and making the functional changes through configuration and not code.

Finally, there are just some changes that you cannot make though “clicks” in Salesforce. At that point a developer will be needed to do such things as creating custom Visualforce pages, Triggers, Webservices, or Batch jobs.

Start small, grow as needed

Having a small team means that there are less issues with communication and we find the group to be more efficient, tighter and more nimble when change occurs. Within those three team members there is flexibility for the responsibilities to shift.

In a similar scenario, you could have a team of three with a Project Manager/Administrator, an Architect/Developer, and a Business Analyst. While the initial example of a team organization is most generally optimal, there are certain projects or circumstances that require team members to pick up other responsibilities.

Perfect fit for Agile methodology

In comparing standard development projects with Salesforce projects, we shouldn’t leave out HOW you work in the different scenarios.

There are many ways to run a software development project and one of the oldest ways is using a waterfall methodology. That’s the idea of starting off with gathering requirements for a whole system, then design, then development, then testing, and finally going live to production.

Get Agile in your development

In recent years several “iterative” methodologies have come about that are well suited to software development. One such methodology is the Agile methodology. The basic idea is that you deliver the project over time in “slices” in several cycles or iterations.

With Agile methodology you should, after each iteration, have some “slice” of your project completed to a point that a user can physically interact with it. Then they can provide feedback. No matter if the feedback is good or bad, it’s perfect because you capture any changes early on when it is easy to change.

On top of that iterations are normally short, lasting one to three weeks. So the users are getting their hands on the system early and can shape it.

A lot of times it is difficult to do a 1-to-3 iteration in a traditional software development process because teams find it hard to just implement enough to thoroughly test a slice of functionality. Having to figure out how to implement a small portion of database setup or network setup while developing a usable part of an application is usually going to take more time that just the one to three weeks in a standard project.

Little coding required

In Salesforce, you can make a lot of changes through configuration and get almost instant functionality in a few clicks.

Then when you have to resort to code, the Apex programming language is flexible enough to give great amounts of customization with very little amount of code compared to other programming languages in other software development projects.

The focus is on business functionality

As we discussed earlier Salesforce has all the “plumbing” set up for network, database, and many more infrastructure pieces. Salesforce.com and its Force.com platform have the database infrastructure set up and part of what you are getting with the platform is its database uptime and scalability being managed by Salesforce’s world-class team.

While you still have to worry about setting up the data in the database, it’s super easy using the Salesforce Admin console. Within a few clicks you bring up a whole set up Objects (similar to database tables) to start working with.

Ease in networking

As for dealing with the network, it’s easy. As long as you have access to Salesforce through a browser or mobile device you are ready to take advantage of anything you build in Salesforce. No special network changes are needed to get your application available for your team.

If security is a concern, be assured that Salesforce is built with security in mind. All data is routed in secure HTTPS and data is protected with several layers of security.

Back to business basics…and results

What you are left with primarily is dealing with business functionality and bringing ROI back to your department and company. The project team can speak the language of the business and discuss on their terms what they need and turn around and quickly implement those changes quickly and easily.

What is delivered to the customer is a solid system built on Salesforce’s hardened infrastructure and tailor-made with customization built only for the required business processes.

Smart results for Salesforce development projects

We have discussed how Salesforce development projects work best with a small three-person team compared to a much larger team for a standard development project.

We have also gone over how Salesforce projects also are perfect fits for an iterative development methodology like Agile since you can easily work iterations with a slice of functionality in mind. We can be nimble in the configuration and coding environment and make changes quickly in order to get functionality in the hands of a product owner.

Finally, we realized that all this infrastructure of Salesforce that you can build on top of means that we do not have to worry about this in development. Instead, we get to focus on the business functionality and bring about faster ROI.