Top Salesforce project mistakes costing you real money
POSTED : February 18, 2014
BY : Jack Pereira

The importance of strong software requirements is well documented in the IT and Salesforce communities. Several studies have found that requirements problems are the root cause of software project failure, with a failure rate of between 37 and 68 percent – representing millions in wasted dollars! Salesforce project mistakes can cost you in the end.

Effective requirements documentation can be challenging and frustrating. But it’s a worthwhile effort considering the rework, delays and lost value that could result from a failed project.

Strengthening your requirements gathering strategies will make the process more efficient and the outcome more successful.

Help Supercharge Salesforce by avoiding these top Salesforce project mistakes that waste time and money:

1. Project scope not clearly defined or agreed on

57 percent of respondents in our survey cited project scope as a pitfall they currently experience.
Sometimes projects do not have clear documentation of what is included versus excluded. Or, stakeholders have not reached an agreement of what to include in the project scope. This can no doubt lead to significant problems.

We recommend that you outline all high-level components, project goals and objectives in writing. Be sure to include items that others may think are included, but are in fact excluded. Then, gain feedback and confirmation from all stakeholders about the scope.

2. Incomplete requirements

Not having enough detail and omissions can cause significant problems, which can cause some requirements to be missed. Executing a flawless Salesforce Roadmap relies on a diligent discovery process. You must get to the root cause of inefficiencies and gain a thorough understanding of the business and technical challenges and goals in order to develop a truly effective solution.

It is critical to have a systematic approach to requirements gathering through a “cradle to grave approach” – identifying each sub-system and module within the system; a sub-module; and, each of the roles for each of the uses and their tasks. Use a Visio for the system, sub-system, modules and sub-modules, and an effective numbering system.

Also, as requirements are gathered, use the 5 W’s and H approach – who, what, why, where, when, and how.

3. Communication breakdowns

Everyone has probably experienced a communication breakdown in the requirements process at one time or another. Sometimes these can be significant. To strengthen the communications process, we recommend using:
• Examples and stories
• Clear, concise writing approach (read back and edit down)
• Confirmation interpretation
• Active listening
• Fact verification

4. Not the right people or sources of information

Business and systems analysts often leave out key people from the requirements process. Make sure to include:
• All the people that have a role in the system
• People that have an interest in the system
• Decision makers related to the system
• Subject matter experts in the process and technologies under consideration
• Visionaries for the system
• People that have a role on systems that will be integrated with the new system
• People that require special attention

5. Out-of-control changes or new requirements

Changes are inevitable, but out-of-control changes are avoidable. Changes can cause major problems to delivering a project with the right functionality on budget and on time.

Changes must be considered at every stage in the development process. Having a clear definition of the project scope, including what is included versus excluded, can help minimize out-of-control changes. For smaller changes, we recommend documenting the changes and handling them in a future release.

Get our software requirements checklist.

About the author

Jack Pereira

Jack Pereira is a chief cloud consultant at PK. He has held various high-profile leadership roles and has a passion for making companies well-positioned for growth.

Tags: , , , , ,