Small Business Blog from Atlantic Canada

Times have changed. We no longer live in an isolated world. Our competition is not only the guy down the street. The competition is in China, in India, in Europe … all over the globe. For all the new theory, new management principles, there is only one fundamental way to survive in the business world:

Business analyst writes requirement in detail. Architect and Developer review requirements. Many clarifications later, Developer codes module. Module goes to QA. QA find three bugs and the module sent back to developer. Developer fixes bugs and resends Module back to QA. (Developer coding time lost) QA finds the earlier bugs fixed - but now finds the fix introduced five new bugs. Fast forward three months into development cycle and the bug tracking system is crawling with bugs. Quality - whose responsibility is it anyway?

I can’t help but be amused at project job descriptions that begin with: “Our client is in need of Business Analyst/Project Manager”
One person for two roles? They must need a Superman! Does your project manager analyze businesses or vice versa? If you have answered yes to either scenario, then you may need to rethink your project staffing. Your project may be in jeopardy!

Where you have a team of Business Analysts working on a project, all the links on the requirements chain must be strong. Any weak link will cause the project to fail. This means all the business analysts in the entire chain must be competent and on the same boat, working towards the same objective.

The road to business analysis can take a number of forms. The most common (and I suspect the often) road traveled is the IT path. You start your career as a developer and code, code and code. You work your way on from there. The other path traveled is the Business route and that’s the path I took. This path requires you to analyze the organization: its environment - both internal and external, processes, trends, industry best practices, formulate and implement strategies.

If you have been a part of a project you know the detailed planning that goes into it. Right from business analysis to scoping to resource allocation and testing and deployment - you are aware of the work that goes into making a project successful. So if you can do that for a project, why would you not do that for your small business?

Not too long ago I was talking to a prospect about their business analysis requirements for his clients. I left with the impression that the Business Analyst (BA) is viewed just as an interface between the developer and the client? I get a similar impression when I talk to other prospects about their business analysis requirements. Organizations looking at hiring BAs to just act as go-betweens between the client and developers need to rethink this approach.

Anyone who has been involved in any project, knows that the probability of failure is more than the probability of success. Depending on which source you refer, about 30% of projects are canceled before completion, 88% exceeds deadlines or both, average costs overruns are 189% and average schedule overruns are 222%. Successful project completion depends on a number of factors.

To differentiate in a crowded marketplace, you need to think outside the “core-benefits” perception. The best part is no one will try to imitate them since what you do differently is not perceived as a core-benefit. Perhaps such an approach will make your customers root for you. FedEx decided to create another core-benefit: overnight delivery - and it succeeded. Volvo, Starbucks, Nike and all such successful organizations have expanded what the term “core-benefits” mean.