Search This Blog

31 May 2010

Best Practices Rarely Are That

Call it a pet peeve. Call it an annoyance. Call it B.S. Call it lying. Call it what you will, but in my career, a 'best practice' rarely lives up to its label. If there is one phrase I think needs to die, or at least needs to stop being so sorely abused, it is this one. It is not that there is no such thing as a best practice, but its how this phrase is used and who uses it that so frustrates me. What should have been an objective measure of the capability of a process has now been hijacked to be a marketing catch-phrase.

The Who (Not the Band)

The most egregious misusers of the term have to be sales and consulting teams. I can not remember a single demo I've been to where the phrase wasn't used at least once during the discussion. I once considered making a drinking game out of how often I heard the phrase used, but that would only make a bad cliche worse.

Both of these groups are most often out to sell you something. Because they want your money, they will often 'extend the truth' to help you view their product or service in a more favorable light. Their logic is that the better they look, the more likely you are to purchase what they are selling. It makes us, as the customers, feel better to believe that a lot of forethought and research went into the flow of a piece of software.

One of my favorite ways to put a stop to this type of nonsense is to ask to see their research. I ask for a survey or market review, conducted by a neutral party, that empirically shows the best process, that gives cost and efficiency measurements and then shows how the vendor's application follows that best practice. It is at this point when the stuttering and blank looks start up from the vendor' team.

After they recover from their shock of being called out, they'll most likely rephrase themselves, saying what they really meant was that the process they're referring to is something that evolved over many years by working with their many clients and customers. I can not stress enough that a single vendor's belief in their own, biased experience is rarely worthy of the title 'best practice.' They may have knowledge expertise in a specific domain which may translate into a better process than you could design on your own, but that does not mean it is the best.

Even if you give the vendor the benefit of the doubt, when you ask the vendor for their process documentation, they will likely not have anything to show you beyond useless whitepapers written by their own implementation teams or training material for the application. Only once in my 9 years as a business analyst, working with dozens of vendors, have I had a vendor that maintained process model information on which their application is based. Even that vendor was unable to explain how their processes, which were really good processes, were truly a best practice.

It is also a misuse of the phrase to equate a best practice with a specific software feature. A best practice can contain a software element, but is not, in my opinion, only a software element. If it is just software, then its a system workflow. I once had an implementation consultant try to tell me that a drill down and two additional navigation clicks for changing warranty dates on a product were a best practice for the industry. As I learned more about the application in question, it became obvious that this was a design limitation masquerading as a best practice. It was something that could be done with fewer steps and no drill-down, but it was easier for the consultant to tell me that it was a best practice than it was to fix their software to be more efficient.

Stakeholders, too!

But its not just sales or consulting teams who misuse this phrase; our business users can be nearly as bad. Usually when I hear a project stakeholder bring up this subject, they are doing so out of a desire to better understand what they should be doing in their business area. Its good to have a stakeholder who is trying to find ways to make their teams more effective in their duties, but asking a vendor this question only perpetuates the problems already mentioned. Its like asking the proverbial fox to watch the proverbial hen house. A vendor is only going to tell you how they do it right and build a case for why you should do it their way.

Another way stakeholders get into trouble by asking after best practice is to have a faulty assumption about what a best practice is. The question is asked in such a way as to lead to a specific, singular answer, but it is rarely that cut and dry. Consider if you will the concept of customer relationship management. How would you design a single best-practice for all companies? Or even for a single industry? What about a single market? This is an absurd question to ask because there frankly is no 'right' way. Yes, some ways are better than others, but the 'best' way depends upon not only who your customers are but on how you manage customers internally to your business. A 'best practice' for one company could be diametrically opposed to a 'best practice' for another company in the exact same industry.

A third failure stakeholders often face when confronting best practice is assuming that anyone can really tell them what it should be for their business. That's not to say vendors can not help, they most definitely can help, but they are there to advise, not design for you. Stakeholders who don't have well defined process and don't want to take the time to map out what they need often look for a vendor who is willing, for a usually exorbitant amount of money, to do the work for the stakeholder. This frees up the stakeholder to focus on managing their current business without all the time and heavy thinking required to actually create a process that fits their needs.

So what really makes up a best practice? Check back soon for part 2 of this blog to find out that information!

28 May 2010

Ready, aim, fire

I suppose I am an early majority adopter of scrum.  After a couple of years working with it my ideas about what makes it work and it's deficiencies have firmed up,  It's an excellent model for managing a team.  It's not for everyone.  The best way I have been to scale it is with well implemented project management techniques for example the WBS.

One of the best things about scrum is that it quickly becomes apparent what the bottlenecks are.  The downside (depending on who you are) is that these are likely either team members or the project owners.

For many of us these are incredibly hard obstacles to overcome.  Which is the harder for you will depend on your circumstances.

Sponsors, in my book are the easier to deal with.  Not because the solution is easy to implement, but because there is only one real way to deal with the problem.  Build trust through a personal relationship.

Poor performers on the other hand... Many project managers do not have hire/fire authority.  The pathway to solving this problem lies in clear reporting of the consequences of no action.  This can go both ways - up line to the sponsor and down to the poor performer. In some places there may be little or no consequence of poor performance.

What then?

Now, on the topic of aiming and firing - some cannon work;

24 May 2010

Managing Stakeholder Sign-off

It is Friday afternoon at 4pm on a holiday weekend. Your requirements document is finally finished, only two weeks late and twice the planned length. The process has been fraught with contention and divisiveness. Yet you, the masterful BA, have managed to gain approval from all but one stakeholder. You spend the last hour of your day before that long, glorious, well-deserved time off in a frantic race around the building, hoping, praying, that the one remaining stakeholder who needs to approve the document hasn't already left for their houseboat on the lake.

I've done that marathon more times than I care to count and know that, sadly, before too long, I'll be doing it yet again for some future project. It seems an unavoidable part of life as a BA to comb the hallways and isle ways hunting for that most elusive of creatures... a signature.

But does it have to be so? There are many reasons stakeholders avoid putting pen to paper. Some don't understand what they're being asked to sign because they haven't bothered to read the document or they read three sentences and were lost with all the 'technical jargon'. Others simply don't want to be held responsible for anything and will thus delay and avoid attaching their name to anything that could be later used to blame them for a failure.

Over the years, I've done sign-off a number of different ways. Some times its with a limited group, others with the full project team. Sometimes its based on title, other times on project role. I've even done a few digital signatures via email, for those stakeholders who work in other countries. Most of the time though, it has been plain pen on paper.

There is something to be said for a physical signature. It gives a weight or a gravity that an electronic signature often fails to provide. For some, the idea of writing their name, the same act they perform when signing a contract or endorsing a check, makes the whole process of sign-off more real.

It is with that in mind that the idea of digital 'wet' signatures caught my eye. Honestly, I don't see this idea taking off, but the entire concept made me curious as to how it would be received in a project setting. What do you think? Could a process like this be the first step in gaining acceptance of digital signatures with your stakeholders?

21 May 2010


I must admit, this is sheer genius and I am jealous this idea never occurred to me. This is a person who can find a way to make it happen. If I ever find myself in the job market again, I will remember this. If this guy ever needs a job as a BA, I can only suggest that you hire him immediately.

18 May 2010

The Surprising Truth About What Motivates Us

Great illustration by Cognitive Media of Daniel Pink's presentation at the Royal Society for the encouragement of Arts, Manufactures and Commerce (RSA) based on his book "Drive: The Surprising Truth About What Motivates Us".

PowerPoint... Friend or Foe?

A few weeks ago, an article from the New York Times website regarding the use of PowerPoint in military briefings began to circulate around the internet. I didn't comment on it when it first came out, but would like to share some thoughts about BAs and PowerPoint that go hand in hand with the article.

If your primary vehicle for a status update is PowerPoint, you've got a larger issue in the mentality of your organization. PowerPoint is a tool and like all tools, they should work for you. PowerPoint is for presentations and there are some things that are so complex that they simply cannot be summed up with bullet points. I won't go so far as to agree with one of the quotes in the article that the application makes people 'dumb', but I will say that it can definitely make you lazy. 

Using any presentation software can present the false promise of making difficult information accessible to anyone, but the truth is, your information is only as accessible as you want it to be. It doesn't matter if you're using a Microsoft product, Lotus Notes for email or an Adobe product for a graphic, if you don't take the time to show the relevant information in context then you are deliberately wasting the time of everyone who will see your end product.

The graphic that is shown in the article (and included in this post for reference), is amusing as an illustration of this principle. Can you look at that graphic and honestly say that the person who created it wanted to convey information beyond 1) they really know how to make a snappy looking graphic and 2) they desperately wanted to look really smart. A better approach would have been to remove all the detail from the graphic and reuse that information on subsequent slides. You keep the initial graphic at the high level, then drill down into deeper levels of detail as you unfold your presentation. At the end, pull it back up to a high level and summarize the key points.

But I understand the mentality to not follow those steps, mostly because I pioneered what I eventually began to refer to as "The Slide That Just Won't Die." My boss asked the team if we could put together a slide that shows all the interfaces in and out of the system we were implementing. I spent hours putting my version together and in the end it was selected as the one that would be used for an executive presentation. It had around 20 interface paths and a dozen or so systems. It frankly looked like a birds nest made of multicolor yarn. I remember being insanely proud of this chart that did such a great job of showing the complexity of our solution. I gave them complexity alright, but what I should have been striving for is clarity.

My slide didn't get its nickname for several months, namely because of how far through the organization it spread. About 6 months later it made an appearance when a VP was asking my opinion on how she might include it in a presentation she was putting together. That doesn't seem such a big deal until you understand the VP in question had no idea I was the author of the slide. It had gone so far around the organization that its source, me and my team, were no longer even connected to it. Yes, I did laugh about it, but only after I got away from the VP.

I have no idea how many times that slide was shown to how many people, but I do know that most of them walked away utterly confused by my monstrous creation. Just call me Dr. Frankenstein. I wouldn't be surprised if it was still floating around in that organization given the couple of years worth of viewings it got while I was employed there.

So I implore you all, don't create a monster. Keep your PowerPoint slides simple. Keep them focused. Make yourself and the necessary information the focus, not your ability to put together a slick yet useless slide.

16 May 2010

Scrum + Business Analyst + Prezi = this

Get one of these today!

13 May 2010

Leaks, Matches and Traps

I've blogged about the book before, but I just have to keep going back to William Easterly's book entitled The Elusive Quest for Growth. Even though the book's subject is economics, it has so much that applies to us as project people. In this post I'm going to cover a small slice of his book regarding Leaks, Matches and Traps


I'm going to take a right turn for a minute and consider the concept of diffusion, where molecules that are highly concentrated in one area move to areas of low concentration. Molecules leak (figuratively) from one area to another. If you had a high school biology class or chemistry class, you've probably heard of this concept.

Knowledge has a very similar property as it leaks as well, from areas of high concentration to low concentration. When you stop and think about it, this is a very intuitive concept. People value knowledge because of what it can bring to them. Increasing knowledge leads to better processes, leading to more value included, leading to a greater opportunity to create wealth.

Wealth in this instance doesn't necessarily mean money, although that was Easterly's original intent, but it can mean project or organizational wealth as well. As our knowledge and understanding about how to work on and run projects increases, so to does the 'wealth' we provide to our employers.

But this type of leak is not something that is a constant. Leaks must be continually monitored and invested in for them to be of use. If there is no new knowledge coming in to your organization, then no new knowledge can leak out to your project team. You can insert more knowledge into the system by utilizing training courses, reading blogs such as this, receiving additional formal education or even hiring in new individuals with a different background than existing team members.

What your goal for using leaks should be to continually 'prime the pump' so that you are creating a virtuous cycle. You know you reached this point when you've put enough knowledge into the system and peaked the interest of enough team members that they start putting their own knowledge sources into the system without you needing to push as hard as you did at the beginning of the process.

Lets go back to our diffusion example for a moment as there is one very important way knowledge is different from diffusion. In diffusion, there is a finite number of molecules to move in order to reach equilibrium, but knowledge is different. When knowledge leaks, it doesn't leave its source, but a copy is made. Now both source and destination have the same information; it has multiplied. Once it has copied, it can be copied yet again. Leaks build on themselves in a way diffusion never can.


Have you ever wondered why there are so many doctors from India who reside in developed countries such as the US and Europe? Why has that one country exported so many of their very smart people when that country so desperately needs those smart individuals to stay at home? This is the concept of matches.

The basic principle here is that workers of similar skill tend to clump together, to match their skill with others of similar skill level. The economic principle becomes apparent when you consider our Indian doctors. Once they have acquired their certification, they face a tough choice; they can stay in their country and make a relatively small amount of money or they can put their skills to use making a lot more money in a country that is set up to better support them. Doctors in the western world typically have a better office infrastructure, supporting personnel (nurses, office managers, accountants, etc) and technological advances (billing systems, electronic records, etc) that make it possible for a highly-valued individual to better use their resources.

Another good example of matching is Silicon Valley. While its true that not all computer innovation comes from this one geographic region, just like not all Indian doctors leave India, an abnormally high percentage of innovative technology companies are located in this area because people of like skills clump together.

Taking this further, because places like Silicon Valley have so many motivated, like-minded people, knowledge there leaks even faster than it does elsewhere. The internet is a phenomenal tool for moving and acquiring data, but being able to turn that information into knowledge and skills requires more than just an efficient means of communication. It requires people to intentionally put themselves in a place where they have the most opportunity for knowledge to leak and for those leaks to add the most value.

For projects, we see this same concept. My very first project was a collection of the best and brightest individuals from all over an entire division of a fortune 500 company. We were brought together with the intent of creating world class processes and systems for the company. Those of us brought in were all highly motivated, knowledgeable and talented individuals (if I do speak for myself). Its no coincidence that we generally got along really well as we all had generally the same goals and desires. As Easterly would say, we matched.


Probably the most difficult to stomach, for me anyway, section of this book was the few short pages on traps. While the concept isn't all that difficult, as it is essentially the opposite of a match, the example provided by Easterly hits uncomfortably close to home. While you can point to many places around the world that are trapped economically, its not just third world countries. Even the US has several regions with large traps and I happen to live adjacent to the largest one, Eastern Kentucky.

People without an economic incentive to upgrade their skills will rarely do so on their own. Things get worse when those in their immediate area also have no incentive to upgrade their skills. Instead of a virtuous cycle mentioned in the leaks section, you get a vicious cycle where people are trapped into their current level of knowledge because there is no easy access to knowledge leaks.

There are two ways for an individual to escape a trap: flee it or rely on outside assistance. Fleeing sounds great, but there are often many things outside of work that make people fearful or reluctant to leave the trap. Outside assistance is good, but only if it is sustained and correct for the trap. Regardless, it is highly unlikely that anyone can escape a trap without some type of external influence.

Corporations often get trapped, just like people get trapped. Think about what happens when a new CEO, with different policies and business plans takes over an established business. Often times the top talent flees due to the uncertainty brought about by such a change in the direction of the company. Unless that new CEO can attract and retain talent, they are on a path down a vicious cycle from which they will have a great deal of difficulty exiting.

Closer to home, we see this in projects. It is never enjoyable to be on a project with resources who don't have the skills and abilities to be successful. Those projects, if they do reach completion without being put out of their misery first, have for me always been over budget, late and under-delivered nightmares.
So how would you apply the theories of Leaks, Matches and Traps to your project team?

11 May 2010


I had a look at a page at "The Plan Is" that ranks #PMOT twitter activity by user.

For those that don't know the #PMOT tag denotes a message for the Project Managers On Twitter.

Of course mst people on the list are  bloggers or forum posters and active in the online PM community.  But two things stand out for me about this.  

Point 1. What the hell are you getting done at work if you are posting upward of 200 tweets in a day?

Point 2: Oh okay, you are using a whole bunch of automated processes to push out tweets, so you aren't in fact spending your whole working day pasting in URLs of interesting content.  So you are spamming.

For me Twitter's eventual failure is apparent in these two points.

9 May 2010

What's so good about scrum?

In all the Agile/Scrum certification and training discussion's I've read on the web in recent months, the most interesting thing I've seen is this little graphic, which was a mere footnote on a Ken Schwaber post.

Why is this interesting?

Because scrum is "just a methodology."  It's a good one, and it's very tightly integrated as a process.  But, a process (or framework or whatever) is just a process.  What's most important is the principles and values behind it.

This graphic nicely summarizes the values behind scrum.  Do they align with yours?  If not, maybe scrum is not for you.

Goodheart's Law and Projects

An interesting phenomenon I've noticed during testing phases of projects is that the number of defect reasons tracked grows the longer the project drags on. It is as if in order to shift blame away from people and onto processes and systems, we create increasingly elaborate ways of explaining away and obscuring the real problems faced during a development cycle.

In light of that observation and similar observations during other phases of the project lifecycle, I was intrigued when BoingBoing linked to a concept called Goodhart's law. The basic principle is that once a measure becomes used as a way to target specific behavior, the usefulness of the measurement itself decreases significantly. If you look back at my example of defect reasons, you'll see the principle at work. Lets put together a quick scenario to illustrate this...

A project has just gone into its testing phase and a QA team member logs a new defect. The defect goes through triage and is assigned to a developer. The developer looks at the code and verifies that the behavior described is reproducible, but feels that the code is working as designed. At this point, he changes the defect reason from 'code' to 'requirements' and reassigns the defect to a BA.

The BA reads the defect and believes the developer misunderstood the intent of the requirement and thus the solution as implemented doesn't fit with what the business area needs. The BA adds additional comments to the defect, reassigns the bug to the solution manager and changes the defect reason back to 'code'. The product manager, protecting her developer, has a new status added called 'enhancement' and pushes the defect back around to the business owner.

Time passes and this scenario repeats itself over months and years. Every few iterations of the product, a new defect reason is added to cover a new outcome that was previously undiscovered. Eventually, there are so many codes that it looks like each group is doing a fantastic job because it only has one or two defects per reason per release cycle, regardless of the fact that the aggregate defect total is continually increasing.

Those of us who have been involved with many projects laugh at this scenario because we've seen it happen all too often. Its not that such detail is inherently bad, its just not necessarily useful the as projects progress.

Its not just testing where we see this type of behavior, either. We see the same thing happen when determining which projects to undertake, eliciting requirements, analyzing requirements, creating project plans or just about any other part of a project.

So what do we do about this? Do we refuse to ever create new defect reasons? Do we stop using defect categorizations as a metric for project and team success? The answer really comes in trying to understand what behavior you are targeting and what is the best way to achieve this new behavior. We need to take a long and thorough look at the real problem and then model how different potential solutions will impact the organization. If we are not performing a deep and comprehensive analysis prior to implementing a change, we greatly increase the risk of having our solution be nothing more than a new problem.

8 May 2010

Who decides YOUR project’s requirements?

From the previous posts we can be seen that different reviewers interpret project requirements in different ways.

Each one of them is right in their very own way and each one of them have their viewpoints from their own angle.

For the success of the project what is more important is to have all the stakeholders of the project brought to a common level of understanding. It's better to identify in the early stages of the project who from the customer's end would take business decisions on project requirements so as go ahead smoothly with the next planned project activity.   

Who’s deciding the requirements on your project?

Nilesh Raje works as Business Analyst with SYSTIME Computer Systems Ltd. based in Mumbai. He also has his articles published earlier with RQNG, International Institute of Business Analysis, ProjectTimes, Business Analyst Times and ManagementNext magazine. He's been a reader here for a while and has proposed this question;

Who decides a project’s requirements?

7 May 2010

Who decides a project’s requirements? Testers?

Testing Team: A benchmark of quality

Well-defined project requirements should enable the testing team to develop accurate test cases to verify the functionality under consideration. It is vital that the testing team be involved in the project from the requirements elicitation milestone.  

The quality team views the requirements from the following aspects: 

What ever may be the requirements the quality team would view for the following key attributes which includes the system’s performance, response time, handling load and transactions of the system.

After studying the business requirements and review of the spec the testing team starts with planning, designing, and executing tests cases for features that need to be released upon customer’s requests.

Where developers go upon assumptions testers expect the product to behave differently from what the developers have developed thereby resulting in an overall cycle time delay.

Some times very little time is given for the testing team to test the solution. In case the project is running behind schedule the testing milestone may be not given due importance.

Nilesh Raje works as Business Analyst with SYSTIME Computer Systems Ltd. based in Mumbai. He also has his articles published earlier with RQNG, International Institute of Business Analysis, ProjectTimes, Business Analyst Times and ManagementNext magazine. He's been a reader here for a while and has proposed this question;

Who decides a project’s requirements?

6 May 2010

Who decides a project’s requirements? Developers?

Development Team: Requirements to code 

Developers are those members of the community who are more inclined as well as responsible for writing and coding individual programmes from specific requirements.

After review they interpret written business requirements and technical specification documents and perform coding.

Developers view the requirements from a technical angle in terms of data dictionary, tables, user interface, reports formats, integration etc. When questions like these are raised during the time of requirement gathering they witness a total disconnect because not at all business users are technically educated. Discussions like these only dilute the interest level of the conversation.

Where requirements are not clear the developers make assumptions. Ambiguity in requirements results in waste of time and developers end up developing a solution, which does not meet up with the customer’s requirements.

Developers at times end up giving more than what is required by the customer in an attempt to please them with “gold plated” functionality. One should deliver only what has been asked for and anything extra that is delivered should be given only with prior customer approval.

Some features required by a customer may have technical limitations and the turn around time required to implement the same may also be quite high. Certain new requirements can detrimentally effect the performance of the existing functionality.

To avoid such cost of re-work a requirements stakeholder should respect the developer’s view of the requirements.  

Nilesh Raje works as Business Analyst with SYSTIME Computer Systems Ltd. based in Mumbai. He also has his articles published earlier with RQNG, International Institute of Business Analysis, ProjectTimes, Business Analyst Times and ManagementNext magazine. He's been a reader here for a while and has proposed this question;

Who decides a project’s requirements?

5 May 2010

Who decides a project’s requirements? Project Managers?

Project Manager: A Quantitative Analysis
Project Manager’s view to invest more efforts of the project plan for software development rather than giving adequate time frame for gathering software requirements. Project manager’s view requirements by doing a quantitative analysis and it’s associated impact on the project plan.  

Some of the challenges faced as far as requirements go from a Management View as are follows:

Project Manager view requirements in terms of the cost of the resources involved and the time frame it would take to implement functionality in line with the defined standards and control processes. 

Requirements serve as the baseline for an successful project design. Project Manager should ensure that the resource who would be dealing with requirement gathering should have some hands on experience in requirements engineering practices and that the same is well understood and well communicated.

Project Managers have to ensure that as and when one incorporates new project requirements is the project team able to still stick to their original schedule as per the available resources. If not then they should immediately renegotiate on project commitments wherever there is a change in the requirements.

Managers need to thoroughly review the project documents prepared by the analysts and should there be a discrepancy they should communicate the same in the early stages of the project itself otherwise it would result only in re-work and detrimentally effecting the on going project delivery.

Nilesh Raje works as Business Analyst with SYSTIME Computer Systems Ltd. based in Mumbai. He also has his articles published earlier with RQNG, International Institute of Business Analysis, ProjectTimes, Business Analyst Times and ManagementNext magazine. He's been a reader here for a while and has proposed this question;

Who decides a project’s requirements?

4 May 2010

Who decides a project’s requirements? Sales?

Pre Sales Teams: Do they generate trust? 

Requirements given by the pre sales consultant many times conflict with what the developers think and they could build. The problem here is only a high level input is provided from the consultant having not much visibility of the product to be developed.  
A Pre Sales Consultant would usually view the project requirements from the following angle: 

They conduct requirement analysis and pre-assignment studies at customer’s location by giving product demonstration & walkthroughs to prospective clients, resolving pre-sales issues & handling questions differentiating our product from other competitors.

Pre sales are also responsible to respond to prospective customer questions and observations. They should educate customers and prospects understand the benefits of the product.

Provide help in giving feedback to stakeholders regarding the product features and functions and ensure that the product offered best matches the customer needs.

Once a particular product is successfully implemented the pre sales view the project requirements in identifying sales opportunity for the product, prepare proposal documents and market the same in competitors market falling under the same vertical or domain.

Nilesh Raje works as Business Analyst with SYSTIME Computer Systems Ltd. based in Mumbai. He also has his articles published earlier with RQNG, International Institute of Business Analysis, ProjectTimes, Business Analyst Times and ManagementNext magazine. He's been a reader here for a while and has proposed this question;

Who decides a project’s requirements?

3 May 2010

Who decides a project’s requirements? Business Analysts?

Business Analyst: Catalyst for Requirements 

The Business Analyst holds the primary responsibility to elicit, analyze, validate, specify, verify, and manage the real needs of the project stakeholders, including customers and end users. The requirements analyst serves as a catalyst between the customer and the software development team and is responsible to bring all the stakeholders to a common level of understanding. 

A Business Analyst would serve as an agent and views requirements from the following angle: 

Apart from requirement gathering, interviewing the users they would be responsible to create prototypes or wire frames to demonstrate a non-working model to the customers. Customer can get a fair idea looking at the wire frames how the proposed solution would look like.

For any queries or concerns towards any aspect of the planned project activity it is appropriate that a BA defines a clear process in identifying the key points of contact in the project engagement with proper escalation mechanism.

Business Analyst (BA) analyses, documents, manages and presents the project requirements for review and approval to the customer in a most comprehensible manner. Analyst should communicate to the customer in the early stages of the project the standard templates and requirement management tools they would adhere to in order to document the requirements specifications.

For a BA getting a requirements sign-off would mean a formal agreement with the project stakeholders, stating that the contents of the requirements document, as drafted, are complete to the final projections and that there are no open issues left to be addressed. It is an expression of the output of requirements gathering to all those concerned with the project.

Nilesh Raje works as Business Analyst with SYSTIME Computer Systems Ltd. based in Mumbai. He also has his articles published earlier with RQNG, International Institute of Business Analysis, ProjectTimes, Business Analyst Times and ManagementNext magazine. He's been a reader here for a while and has proposed this question;

Who decides a project’s requirements?

2 May 2010

Who decides a project’s requirements? Customers?

Customers: Are They Always Right?

Anyone who derives direct or indirect benefit from a product or service offered is a customer. It’s not necessary that the customer may be always right. However, the customer has a viewpoint and one must understand and respect customer’s viewpoints rather than forcing developers to determine among the customers who do not agree with conflicting project requirements.

As a software customer one would be primarily responsible for the following activities: Customers at times believe that the analyst or the member from the development team should already know what the customers need. Defining business requirements is not the ownership of the customer but the project team.

It would be ideal if the analyst is given the pulse of the current systems and processes coupled with existing documents to educate them about customer’s business concepts and terminology.

Customers usually don’t find it significant to invest time with the project team for requirements gathering or elicitation activities. Sometimes customers get so busy with the key responsible areas at work that they usually don’t give justice to the requirements gathering activity and the requirements gets captured just on assumptions.

Customer needs to prioritize what requirements are crucial and critical to the project. Requirements, which are vital, need to be delivered on priority whereas those that are good to have features can be delivered phase wise. Customers have to understand that not all requirements can be given at the same time. Phase wise delivery would be ideal.

Nilesh Raje works as Business Analyst with SYSTIME Computer Systems Ltd. based in Mumbai. He also has his articles published earlier with RQNG, International Institute of Business Analysis, ProjectTimes, Business Analyst Times and ManagementNext magazine. He's been a reader here for a while and has proposed this question;

Who decides a project’s requirements?

1 May 2010

Who decides a project’s requirements?

Nilesh Raje works as Business Analyst with SYSTIME Computer Systems Ltd. based in Mumbai. He also has his articles published earlier with RQNG, International Institute of Business Analysis, ProjectTimes, Business Analyst Times and ManagementNext magazine. He's been a reader here for a while and has proposed this question;

Who decides a project’s requirements?

I’ll give the bog over to him for the next few days to explore this issue. Jump in and offer comment as we go.

Here is Nilesh.

Every Project Has Requirements

I am sure most of us would agree, “Every Project Has Requirements”. Some requirements are crucial to the product, while others are gold-plated luxuries. Explicitly or implicitly, there is always someone from the project team who performs the role of requirements gathering for every software project. 

Determining the project requirements is vital in developing successful software as they form a baseline between the IT team, the customers and the stakeholders on what features will be delivered in the new system. 

Requirements just don’t come from one source – the development team. Multiple stakeholders are involved as far as requirements are concerned. White paper under consideration would consider the key responsible areas of each of the stakeholders when it comes to determining software project requirements and who own them.  

Requirements Stakeholders 
Your browser may not support display of this image.  
From the above it is evident that software requirements just don’t come from a customer. Requirements come in from all direction which includes: Customers, Business Analyst, Pre Sales Team, Project Manager, Development Team and Testing team. It’s imperative that one identifies at the beginning of the project who takes the ownership for defining the project requirements. If this is not resolved in the early stages of the project then the ownership falls on the development team by default or the requirements would form to be a part of the change request.

Over the next posts we will review the following

  • Stakeholders

  • Customers

  • Analysts

  • Sales teams

  • Project Managers

  • Developers

  • Testers

Please follow this series and offer your comments.