Thursday, August 29, 2013

Common & Practical Problems of Requirements Elicitation

Requirement elicitation is an important and challenging phase of any software project. This holds good for both product and project development activities, but the approach, techniques might vary. A well specified requirement has been found to considerably improve success rates of projects. Though various methods and techniques have evolved over the last couple of decades to better produce a good requirements specification, many struggle to get it done well.

This could be mainly because that requirement elicitation is just not science, it is an art too. It is more an art because it is highly human intensive and much depends on the skills of the people involved in the process. More so, as which method or technique to use and the way the document is structured and written depends on the abilities of the person driving this activity. Based on my experience in the be-spoken project development and product development activities, I have listed down some of the most common and practical problems with this activity as below:

1. Preconceived Notions

The requirements of every customer even in the same business domain, would be different. For example, requirement of a bank X would not be the same as that of bank Y. Each enterprise would have different business processes to differentiate their abilities or value deliveries from their competitors. The teams involved in requirement elicitation shall start with a clean slate for every project and thus should not try to bias the elicitation work with their previous project experience in mind. Ignoring this principle would result in misaligned requirement specification and thus ending up delivering a deficient product. As this is a human intensive process, it is quite common for the customer representatives too to easily miss out on such things.

This is quite a common problem with the product companies. Irrespective of whether the client contracts for the product with customization or a project, the vendors would prefer to reuse their existing code assets. As such, the business analysts engaged in the requirement elicitation tend to scope the customer requirements in such a way that it fits within the existing product architecture and related constraints. Even in case of a product based contract, the requirement elicitation or the gap study shall focus shall be unbiased and then it is the Solution Architects who will come in to come up with solutions to bridge the gaps. In the process, the customer will have the option to decide to dilute his requirement in favor of an existing work around.

The business analysts shall master the art of unlearning and relearning to handle this area well.

2. The Design Mix-up

The next common problem is to mix up the requirement elicitation with the solution design. This happens on both the sides i.e, the vendors and the customers. The business analysts from the vendor side often would start visualizing the solution design with a specific use case and would start suggesting deviations or work around to the use case. Similarly on the customer front, the users may start talking on the system perspective. For example, customers when narrating the requirements might talk about a drop down list, check boxes, etc. Ideally such details should be left to the design teams and where appropriate, the customer might want to review those designs or might specify the design guidelines to be followed or specify usability requirements for the vendor to conform to.

There is another school of thought that visualizing or thinking of solution early on would eliminate feasibility issues down the line. While this is partly true, the problem arise when such design constraints hide the underlying actual business requirement, which could lead to mis-interpretations later on.

3. Poor Planning

The requirement elicitation has to be a planned process with proper entry and exit criteria for each of the sub processes. There are many frameworks and techniques to perform this activity. Irrespective of the methods or techniques, the elicitation process shall comprise of the following activities: Identifying the Stake Holders; Define Use Case specifications; Generate scenarios;Organize walk throughs / interviews; Document Requirements and Validate Requirements. It is quire possible that each of these activities might have to be performed in multiple iterations. Poor planning of these activities might result in ambiguous or deficient requirements.

A related key issue is the exit planning. i.e. when to consider the requirement elicitation as complete. Depending on other project constraints, the exit criteria has to be carefully identified and further planning should be around that. For instance, if time is a key constraint, just for the sake of meeting the timeline, the elicitation activities should not be hurried up and thus ending up with an imperfect specification. Instead, in such cases, the scope can be divided into broader sub components and agree with the customer to defer some such components to a later phase based on priorities. Agile approach could also be thought of to solve this situation. i.e. start eliciting the requirements as specific user stories are taken up in respective sprints. A careful consideration of all the project constraints and priorities is a must in choosing a solution and there by coming up with the best course of action.

4. Volatility

In one of the projects we were handed off with a four hundred page requirements specification document was an year long work of the internal business analysts of the customer. But it was no surprise, that the actual business requirements were far different than it was documented as the business practices and processes  have changed a lot during this very same period. This has been a common problem that the industry has been battling with and Agile approach is emerging as a solution to this problem. This volatile nature of the business requirements requires the solutions to be delivered quicker to reap the time to market advantage.

Another aspect of volatility is that the requirements as elicited from different users / departments could be different and at times conflicting too. In some cases such differences could be misstatements or misunderstanding or in some cases it could be genuine, in which case the different requirements shall be specified appropriately and let the design teams come up with solutions to meet all such differences.

5. Undiscovered Ruins

It is the human nature to answer just the questions that were asked. Thus the business analysts shall master the art of asking appropriate follow up questions based on the responses from the customer representatives. That is where the elicitation is important. i.e. the business analysts shall provoke the customer to fully reveal what is required of the system. In the process it is very much common that certain needs might go undiscovered, but would show up later on as a deficiency. This problem can be partly addressed by identifying the right stakeholders for the purpose and then to get those validated by different stakeholders, who would look at these with a different perspective, which might bring out gaps if any.

Saturday, August 24, 2013

State of Open Source in The Enterprise

We all know and keep saying that Open Source is here to stay and there are enough proof out there in the form of companies like facebook, google, linkedin and quite many who have their business enabled by Open Source software. I get what you are thinking, the short list above are those companies who are into social networking kind of business and we need to look at large businesses, like banks. While we can say that the adoption of Open Source software is increasing, the same in the mission critical enterprise software space is still not very visible. For example, big data and cloud computing has triggered the increased use of open source software in the form of hadoop, map-r, open stack and so on. However, with enterprise software vendors also pitching in with their way of addressing similar problems, big enterprises tend drift away from the open source.

What is holding the CIOs back in adopting Open Source in their enterprise software suite? Probably, they see a risk of continued support. In most cases, the CIOs are willing and ready to adopt or try Open Source software for the enterprise's secondary use and leave the mission critical software to be proprietary and fully supported. Java as the open source programming language is well embraced, but in the middleware space, though Apache Tomcat and JBoss share considerable usage, big enterprises still look at weblogic or websphere.

On the website front, Apache and NGINX lead the open source market share and has much wider adoption with enterprises of all sizes. However, with many proprietary content management frameworks emerging, large enterprises are drifting towards the same, so that the website content maintenance and collaboration could be fairly simple with these frameworks. In the mobile world, Android has come into stay and has wider adoption on the consumer side with Microsoft getting increased attention of the enterprises for the enterprise mobility needs.

Similarly, with big data, we see many open source NoSQL and SQL databases emerging and even gets much needed visibility. However, bigger enterprises tend to try these databases for their secondary usage like data warehouse, etc and leave their primary mission critical applications to use proprietary database solutions. When it comes to critical enterprise software, the decision makers go by real world case studies and their market presence and don't want to take risks in going with Open Source.

May be, if we take a closer look at the decision making processes, we can understand, on what grounds Open Source is left out. Typically, the following are the key criteria used for evaluating an Enterprise Software that come in the way of adopting Open Source Software:

  • Support: Looking at it positively, Open Source software gets support from developers across the globe, mostly with a well governed release process. On the other hand, these are not built with the needs of a specific enterprise in mind, but built for a specific purpose though.Thus considerable efforts would have to go in to make an Open Source software work for an enterprise and the skills are scarce. Those enterprise who have their business around IT have plenty of developers on board and will have the ability to customize and adopt and even contribute back. In case of non IT organizations, this will mean a dependency on a vendor who can offer the support at a cost. When the software is expected to be critical for the business needs then naturally, this concern gains importance leading to the decisions drifting in favor of Proprietary solutions. Another thinking is that, though the software comes free, the efforts involved in customizing, enhancing and maintaining it could result in a way higher total cost of ownership than that of proprietary software.
  • Usability: Open Source developers focus on the technology and often ignore the usability aspects and thus resulting in increased costs around user training and maintenance. On the same lines, the end users are expected to use the software at their own risks and no own guarantees or warrants its performance levels. 
  • Concerns on IP: Being open source, the consumers are expected to contribute the changes if any they make to the software back for common use and thus the Intellectual Property of the enterprise might have to go back to the shared source code. In case of proprietary software, however, there could be an option to continue to own the specific IPs though at a higher cost. 
  • Reliability: Contrary to the reality, there is a thinking that in case of Open Source software, the reported issues might get too longer to get fixed or some might not be fixed at all. With community of developers all over the world contributing, Open Source software evolves pretty fast. However, no one could be held responsible though. Other related concerns could be that lack of better governance, absence of adoption by competitors and lack of support from big names.
  • Security: As the source code is accessible for use by any one, there is a tendency to think that hackers can also get to know the software better and design attacks around the vulnerabilities. However, like in the case of fixing issues, some of the open source communities also consider fixing the reported vulnerabilities on priority and making the product secure. The security concern would remain even with proprietary software.

Of all, the concern support and related cost seem to be the primary concern that hold CIOs back from adopting the Open Source software. The traditional methods of evaluating the software may have to be revisited though to overcome this problem. The decision makers want to play it safe.

Of late we see pressure on the CIOs to cut costs where possible and that is a good sign that Open Source Software is getting a fresh look, more so in the Government sector. Those doing business in and around IT are building the needed skills and talent in house and embrace open source solutions. We see this more in the areas of configuration management, build automation, automated testing and other tools which aid in building and maintaining systems and infrastructure. Open Source software is still not making inroads in mission critical enterprise business applications. 

Wednesday, August 14, 2013

Agile in Fixed Price Fixed Scope projects - Hybrid Contracts

It is well known that the traditional methods are not yielding to a better success rate of a project and thus there is a tendency to lean on Agile Methodologies. At the same time, clients feel secure with Fixed Price and Fixed Scope project as their financial outlay is limited and there is no ambiguity. What they miss however in this process is the value delivery. The traditional project management methodologies focus on the Scope, Time and Resources where all three are constraints. Ideally the focus should be on the Value and Quality delivered, given the constraints there by guaranteeing a better success rate of the project.

The software vendors are doing business and they work to earn profits. As such, with Fixed Price projects, the vendors tend to limit their efforts to deliver the agreed scope. With the pace at which changes are happening around any business, freezing scope for a project early on is nearly impossible as software delivered to such scope frozen early on is often less usable. With change is the key driver in optimizing the value delivery, clients and vendors have conflicting views on the change.

Agile methodology has evolved over these years and offers a solution to the problem of optimized value delivery. However, clients still feel that Agile approach does not secure their interests in terms of a definite price and time. Of course, their concern is genuine as they cannot afford to sign a project contract where the cost and time are elastic. While the basic premise of Agile is to embrace the changes, to succeed, it depends on a very high level of trust between the vendors and the clients, where both should work for a common goal and the contract should be profitable to both.

Having said that the Fixed Price (FP) Fixed Scope (FS) contracts offer very limited opportunity for vendors to practice Agile methodology. Making either FP or FS elastic will give some room for practicing Agile methodology. Let us explore how this can be accomplished in the contracts. Both the above contracting models requires a high level of trust between both the vendors and the clients.

Fixed Price Elastic Scope (FPES) contract: In this model, while the price is fixed, the scope can be variable. This model can practice a hybrid Agile approach, the scope is broken down to features and the development happens feature by feature. Depending the time taken to implement a feature, more features are added or removed. For instance, if a feature estimated to take 30 days is implemented in 20 days, one or more new features can be added to fill the time saved. Similarly if the implementation takes 45 days, then one or more features will be removed.

To bring in incentive for both vendors and clients, a discount factor can be agreed upon, which is applied while adding or removing features. For instance, in a case where the vendor has saved 10 days for a feature, the client instead of adding a feature that needs 10 days to fill the gap, will only add a feature with 5 days of effort, where the discount factor would be 50%. The same discount factor is applied on the converse (where implementation exceeds the planned effort).

Elastic Price Fixed Scope (EPFS) contract: In this model, the Scope is fixed, but the pricing is variable. The idea behind this approach to is arrive at a base rate and a profit factor. While the base rate and the profit factor, along with the generic terms and conditions are covered in the Master Services Agreement, the actual project scope can be covered in multiple Statement of Works (SoW). Requirement elicitation and scoping can be the first SoW. This way, the project can be split into smaller working software modules and the work items can be scoped in stages / phases. This approach will help the clients in handling changes with ease.

Here again, an approach like 60:40:20 can be adopted to prioritize the work items. This approach requires the work items to be grouped into Must have features, Good to have features and Fixes. Every SoW can comprise of 60% of Must Haves, 40% of Good to haves and 20% of fixes emerged out of previous deliveries.

The incentives for both vendors and clients can be based on categorization of the work items as New feature, Clarification, Fixes. New features are the scope items as elaborated during elicitation. Clarifications are such items that emerge out of elicited requirements during the design or build phase. Fixes are incorrect implementations by the vendors, basically design and build defects. Costs for each SoW can be computed by applying the profit factor on the base rate. For instance, the New features will be charged at base rate + profit, clarifications will be charged at base rate and fixes will be charged at base rate - profit.

With the above, we are not concluding that Agile cannot be practiced in an FPFS project. There are still ways and means that a hybrid agile approach can be thought of and practiced so that value delivery is the primary focus for all the parties. Do share your thoughts in the form of comments on the subject, and I will cover those in my next blog.