Software Over-engineering Trap - Ways to Avoid them!

Author: Shailesh Goswami, Professional Development Resource Manager, Microsoft Global Services India

[A good read on handling Non functional requirements and Requirements Traceability, sourced by Kuttan]:

To get success in a software project, Software requirements analysis is critical. The new system must be as good in performance as the legacy system Software requirements analysis is critical to the success of a software project.

Inappropriate gathering of software requirements is a major reason for projects not achieving the desired results. A META group research indicates that approximately 60-70 percent of IT project failures occur directly as a result of poor gathering of requirements, analysis, and management. Unclear requirements often increase the tendency amongst software designers and architects to over-engineer the solution. Here we will take a look at the ‘software over-engineering trap’ and the ways to avoid it.

In a recent recovery project, we were called to ‘fix’ the software developed by the customer’s own team. The testing team found that the software, though claimed to be highly scalable, was too slow and unresponsive, especially on smaller number of users. On investigating, we found that though the software architecture used the most fanciful technologies, implemented nifty design principles, and seemed 'perfect', it did not work when deployed. This is a classic example of what I call the 'software over-engineering trap'. Let us take a closer look at why we fall into this trap.

Top Reasons for Getting into the ‘Over-engineering' Trap

1. Lust for using latest technologies:

Being abreast of all latest technologies available in the market, it is natural for software architects to have an inclination to use them. But in the eagerness to use the latest technologies, one should not lose sight of whether it is actually required for the project at hand.

2. Lack of clarity on non-functional requirements:

Often the customer is not able to convey the requirements in the best possible way and may also be not sure on the levels of performance and scalability required. In such situations, the software architects may tend to take the safest route: create a software architecture that is straight from the textbook.

3. Limited understanding of technology at client-side:

Customers may not always have a tech-savvy member working directly with them to objectively review what the architects produce.

4. Background of the architects or designers:

Many times, architects play on their strength. They propose what they know the best.

All problems have a solution. We can avoid the trap, by enforcing some simple and effective steps. I call them 'powers' and I believe in them as if they were God sent. Nothing fanciful, but they really work.

The Power of Non-functional Requirements

In contrast to the functional requirements that determine how the system would behave, non-functional requirements (NFRs - that specify things like performance, scalability, and security requirements) are more intangible and ambiguity prone. But they are critical to the overall success of the software project and can dominate the design and architectural decision. Unfortunately, we tend not to give them their due importance because of the reasons discussed earlier. Both customers and analysts are very good at capturing functional requirements, but capturing non-functional requirements is not as easy. In many projects, NFRs are either not defined or defined very vaguely with fancy sounding open statements or defined very late in the game, almost after the software has been developed. Thanks to Mr. Murphy, the process of capturing non-functional requirements is paved with unusually high number of hurdles and speed-breakers. The end result is that we ignore the NFRs and move ahead in order to avoid delays in the project.

For example, if the customer has minimal scalability requirements, then one must carefully evaluate the need of service-orientedness (assuming no other pressing need for service orientation exists). In our recovery project example, we found that the scalability requirements were not captured properly. In reality, the customer had very minimal scalability requirements, but due to unclear requirements the designers ended up designing a highly scalable multi-layered service oriented system. As a result the system became too slow when deployed in production environments. Most architects know that each design decision comes with a trade-off and clarity in non-functional requirements help us make that decision meaningful to the customer situation.

Here are some guidelines that, when followed, can help us exploit the power of NFRs and make our architecture much closer to the real customer requirements:

1. Make NFRs non-negotiable:

Irrespective of how many hurdles you may face in gathering accurate NFRs, one rule I always follow is to define a clear ‘must-achieve’ milestone by which the customer must give you all non-functional and operational requirements before the team moves to the coding phase. No sign off on NFRs, no movement in the project.

2. Document NFRs in the form of data:

Document NFRs in the form of real numbers and not as open statements. For example, rather than saying, "The new system must be as good in performance as the legacy system," one must get customers to give data in the forms such as - 'the new system must load in less than 1 second' or 'the search page must provide all matching employee records in no more than 3 seconds'. Adopt this data-centric approach for scalability, installation, performance, security, and other non-functional requirements.

3. Focus on deployment:

Look at the way the customer is going to deploy the software after you develop. Would it be deployed on one machine, or multiple servers, or a cluster of machines? Get an agreement on the physical deployment of the software early in the game. I particularly recommend that each team member prints the physical deployment diagram and pins it up on his or her desk.

4. Data flow diagrams and threat modeling for security:

Look at the security aspect very carefully. What level of security is needed? Which portions of the system should be more secure than the others? What access levels and permissions you must provide to various roles that exist in the application? I found preparing a basic ‘data flow diagram’ very helpful in determining what type of security is needed at each level of the software. Using this simple data flow diagram, it’s very easy to figure out where a customer is exchanging personal information that requires higher security versus normal information. Many architects also perform what is known as 'threat modeling' based on such diagrams and other inputs before proceeding ahead with design.

The Power of Traceability Matrix

The capability to map the requirements increases the likelihood of delivering a software product that fulfills the customer’s needs. Using a 'traceability matrix' for this purpose is highly recommended. Most likely, you may have heard about this many times before. However, the simple submission here is that most companies either do a mere lip service to it or prepare this matrix in later phases of the lifecycle.

When used right from the start, this matrix helps us trace back the architectural considerations to real customer needs. Whether the customer asked you to prepare a traceability matrix or not, you should do it in your own interest. In this matrix, one would write down specific aspects of the architecture like componentization, service-oriented-ness, configurability, and dynamic discovery and map them to the customer requirement, especially the NFRs captured earlier. In the next column, one would also write what the drawback of using each of these architectural considerations is.

In the end, you would write down what type of hardware and deployment environment would be needed for this design to deliver results. Once complete, this helps us to re-consider our design in the event it is not mapping to any customer requirement, or is having more negatives than positives. Or, if the hardware needed is much more demanding than what the customer is going to use.

The Power of Demonstrations

As they say, ‘the proof of the pudding is in eating’. And the proof of your software architecture is after you see it running live to your total satisfaction! In addition to delivering software in optimally frequent intervals, you will particularly find the concept of creating ‘min-deployment lab’ very useful. This lab mimics the real deployment environment that customer has signed up for. It has the same firewall, DMZ, domain, and security settings as the real environment would. This environment is first used by developers and testers to deploy the system and perform the testing before releasing the software. Later, the same deployment lab can be used by the customer’s teams for phase-end demonstrations. A small investment in such labs gives great ROI, as compared with the cost of fixing failed projects. Your development teams would be surprised to see your own system not behaving as intended or even crashing when really deployed in this mini-lab. This would help them solve some critical deployment level defects early in the game. If setting up a lab at the development location is not always feasible, then the project teams must look at using the customer staging and testing environments during the development cycles.

In today’s environment, with the advancements in development, deployment, and virtualization tools, setting up this lab has become easier than ever before. Teams that follow agile software development methodologies can conduct phase-end demonstrations of functional and non-functional requirements in this mini-lab to avoid unpleasant surprises in the end.

So here’s to real IT that works for the customer, and for you!

Implementing these methodological and effective approaches to software requirements gathering helps the architects collect, segregate, prioritize, analyze, and document all the relevant informational and process needs for the application under design. This understanding of software requirements gathering will help give you a competitive edge over others.

Unlocking Business Intelligence...

Here is a link to a nice (and long) article that appeared in CIMA, with special focus on Management Accounting, but provides excellent insights into the State of affairs with BI, in general:

http://www1.cimaglobal.com/cps/rde/xbcr/SID-0AE7C4D1-AD3187E0/live/cid_execrep_unlocking_business_intelligence_Feb09.pdf

Marketing your Project

Author : Michael Wood [sourced by Kuttan]

Why do some projects need a marketing campaign and what’s involved in the effort?

To answer this question we first need to understand some basics about what marketing is all about, what a marketing campaign is designed to accomplish--and what role marketing can play in contributing to project success.

First, not all projects warrant a full-blown marketing campaign effort. Projects that have sweeping organizational impact, require large capital investments, tend to be politically sensitive and span more than a year are typical candidates for a formal marketing approach.

As Wikipedia puts it: Marketing is an integrated communications-based process through which individuals and communities discover that existing and newly-identified needs and wants may be satisfied by the products and services of others.

Some projects may even benefit from a branding effort that captures the essence of the project in its name or slogan. Again, turning to Wikipedia, the following definition of a brand can be found: A brand is a name, term, design, symbol or other feature that distinguishes products and services from competitive offerings. A brand represents the consumers’ experience with an organization, product or service. A brand is more than a name, design or symbol. Brand reflects personality of the company which is organizational culture.

Although the benefits of correctly marketing a project can be many, applying these concepts to projects is not always easy. The following concepts are intended to help you in your project marketing efforts.

There are two basic phases to marketing a project. The first phase (pre-approval) deals with promoting the project with the goal of gaining stakeholder support and management’s approval. The second phase (post-approval) focuses on maintaining momentum, keeping the project positioned in a pro-active and positive light and conditioning stakeholders toward the changes the project’s implementation will deliver. This article will focus on the pre-approval aspects of marketing your projects.

During the pre-approval phase there are a few specific goals that your plan needs to achieve. First, it should stimulate thinking on ways to make optimal use of organizational resources. This requires a compelling business case stated in very simple business terms that identify the outcome to be achieved along with the associated investment. For example, consider the following case for improving the effectiveness of direct marketing adapted from a real project:

Streamlining the Direct Marketing system at Acme Widgets will save over $3 million a year in promotional costs while enhancing sales by 15 percent. This can be achieved by the end of 2010 with a dedicated team of 12 and an investment of $750,000.

This example is simple, easy to understand and draws the reader into asking “How?”--and allows for further promotion of the project to interested parties and hopefully garnering support.

In addition to stimulating thinking, the pre-approval marketing effort needs to be clear as to the roles and responsibilities of those conducting the marketing effort. Here, more often than not, less equals more. Communications need to be controlled and deliberate, thus idle chatter among would-be team members to outsiders needs to be managed. Think press releases, not water cooler gossip.

Just as in political campaigns, talking points need to be well thought out and consistent without seeming rehearsed or appearing to be mindless regurgitations of the “party line”. Thus, there should only be one or two project spokespersons that are intimate with the project’s details as well as proficient speakers and presenters. These spokespersons must also have a firm grasp of the obstacles that will need to be overcome in order to sell the project--including lack of credibility, political opponents, scarcity of capital funds and overall economic conditions. For every obstacle identified, specific responses need to be crafted and shaped that bring the focus of the issue back to the benefits to be gained through the project’s implementation.

For example, it is reasonable to expect that both time needed to achieve, the investment identified and outcome promised will draw critics’ eyes. Here, facts--not sound bites--will win the day. By delving deeper into the assumptions supporting the costs and benefits of the project, attention is moved from the end numbers and toward the framework that was used to support those numbers. Thus, those objecting to the project must invest time in understanding the assumptions and how they were used in order to be credible opponents. Using our direct marketing example, the following objection handling talking points might be used:

Objection: How is it possible to save $3 million a year in direct marketing costs via a streamlining effort?

Response: Currently, our direct marketing campaigns average 150,000 items per mailing and are based on a “shotgun” approach resulting in less than a 1 percent response rate (1,500). Using a more scientific approach, based on customer preferences, buying habits and other demographic and psychographic data, our tests have indicated we can sponsor campaigns of 5,000 to 30,000 mailings and yield over 20 percent response rates (avg. 6,000). This alone will save us an average of 75 percent on direct mailing costs while increasing responses fourfold.

Notice how the facts are quite granular, compelling and authoritative. If the person posing the objection is not intimate with the details, they are hard-pressed to challenge. In addition, assuming the facts are correct, additional inspection only serves to strengthen the business case for the initiative. Thus the marketing effort achieves yet another major goal of the plan--progressively advancing the project toward approval.

In their book Innovation Happens Elsewhere: Open Source as Business Strategy, authors Ron Goldman and Richard P. Garbiel share these thoughts related to the story behind your project--your marketing plan:

“A compelling story that describes what your project is aiming at--something to get people excited about it. This is the message that will attract people to your project both as users and potential developers.The story needs to express the shared purpose behind your project. It will attract people who share this vision and are willing to work to make it real.”

In preparing the pre-approval marketing plan, consider the following steps:

1. Develop a business case based on solid facts and research including stakeholders; economic realities; soft and hard investments; time and effort needed for success; and, most of all, what success looks like in terms of improved revenues, reduced costs, larger market shares, new customer capture, increased customer loyalty, etc.

2. Identify the challenges and obstacles that would lead to management not approving the project

3. Craft a benefit statement that draws the reader into asking hard and challenging questions that are easily answered by the facts and effectively disarm challenges and obstacles.

4. Identify the core talking points and spokespersons for marketing the project

5. Define the campaign in terms of media blitzes, campaign presentations, print and electronic media (brochures, websites, video, data sheets, etc.).

6. Define the campaign’s reach, milestones and timetable for completion

7. Test the campaign where possible on prospective sponsors.

8. Develop a detailed proposal and executive level presentation for pitching the project to management and key stakeholders

9. Launch the campaign leaving room for recalibration every week or two.

10. Culminate the campaign with the pitch to management, being sure to have as many supporting stakeholders present at the presentation.

Marketing a project is like marketing any product launch: It requires a deliberate and well-thought-out plan that is geared to achieve one and only one outcome--a “yes” from management. The more grassroots support you have for the project—and the better researched your facts are--the more likely you will be to achieve a resounding “yes” from management.

Good luck with your efforts. Let us know what approaches have worked on marketing your projects and any lessons learned from unsuccessful efforts.