Pre Sales, Software Services

Proposal Building Process in Presales

Based on the size and/or complexity of the project, the study effort may vary. The typical process steps for conducting a requirement study and proposal building are outlined below. These steps are often being conducted concurrently, iteratively and, in fact, some steps may be omitted entirely, depending on the complexity and criticality of the effort. Process steps include:

  1. Determine requirements for the study
  2. Determine objectives, scope and approach, and plan the effort
  3. Conduct a current state assessment
  4. Identify potential solutions
  5. Determine the feasibility of each option
  6. Document and communicate the results of the requirement study, and obtain approval to estimate development for the recommended solution


1.       Determine Requirements for the Study: Business Problem or Opportunity

Requirement studies are used to determine the approach to solving a business problem or seize a new business opportunity, the approach is slightly different. In the case of a business problem, the Business Analyst first determines and documents the problems faced by the organization and the potential areas of study required to address the issues. The analyst then conducts root cause analysis to determine the full nature of the problem, the actual cause (or causes) of the problem, the adverse impact it is having on the business and the criticality and required timing of the resolution.

To take advantage of a new business opportunity, the analyst defines the opportunity in as much detail as possible to understand the scope and determine the nature of the study. This information is then used to determine the methodology or approach to be undertaken to complete the study. For each business problem and/or opportunity, the analyst drafts a requirements statement describing the business need for a solution.

2.       Determine the Objectives, Scope and Approach and Plan the Study Effort

To plan the requirement study effort, the Pre-Sales/Business Analyst first assembles a team of skilled resources who collaboratively perform the following tasks:

2.1   Establish specific, measurable objectives that the recommended solution must meet. These objectives provide the basis for formulating options for consideration.

2.2   Develop benefit criteria upon which alternative solutions will be evaluated in the form of quantitative measurement criteria by which to judge the success of the investment in the recommended solution.

2.3   Define scope of activities to be performed during the study.

2.4   Define deliverable(s) to be produced from the study; if it does not exist, develop a template for the final proposal document.

3.       Conduct a Current State Assessment

The study team conducts a limited amount of internal analysis when initiating the requirement study. These may include review of business objectives, strategy and vision; analysis of current business processes; and assessment of current (as-is) and future (to be) documentation. The current state assessment consists of a review of all or part of these elements, depending on the nature and scope of the study:

3.1   Strategy – Review the business vision, strategy, goals and measures.

3.2   Business Area – Describe the mission of each line of business or business unit that is a stakeholder for the area under study, and collect relevant organizational charts.

3.3   Locations – Document the physical location of each impacted business unit.

3.4   Data and Information – Identify the major types of business information required. It is also helpful to list the repositories which retain the information listed.

3.5   Infrastructure – List each of the current business technologies impacted by the initiative.

3.6   Processes – List and provide a description of each of the current business processes relevant to this project.

3.7   Competitive Arena – Describe the current business environment within which the business operates, including:

  • Market analysis, competition, products and services available
  • Emerging markets and technologies
  • Regulatory or legislative changes.


4.       Identify Potential Solutions

At this point the study team conducts external research activities to uncover general information about the industry, the competitive environment, best practices, risks and results of the actual similar approaches that have been implemented by others to solve the business problem or seize the new opportunity under consideration. Then, the team identifies as many potential options as possible to meet the objectives identified in the planning process. It is important to note that the list of possible alternatives should include the option of doing nothing.

5.       Determine the Feasibility of each Option

For each potential solution, typical analysis steps include the following:

5.1   Describe the solution option in as much detail as possible, perhaps building a high-level work breakdown structure (WBS), a hierarchical decomposition of the solution, to bring the full scope of the effort into view.

5.2   Identify methods to assess the alternative, ensuring the analysis of the economic, operational and technical feasibility of the option. Examples of methods include: prototyping to prove the highest risk portions of the solution option are technically feasible, market surveys to ensure there is a demand for the solution and it will be economically feasible, technology capability assessment to ensure the solution does not require new, unproven technology, and business staff interviews and IT staff interviews to determine operational feasibility.

5.3   Identify expected results of the assessment.

5.4   Define assessment steps.

5.5   Undertake feasibility analysis for each option.

5.6   Review results to ensure completeness.

6.       Document and Communicate the Results of the Requirement Study

Proposal document would describe the results of the requirement study for each identified alternative solution. Share the proposal document with the executive sponsor of the study, and secure approval to estimate development efforts for the recommended option.

Types of Requirement

The types of requirements that exist vary based on the problem domain and methodology that the Pre-Sales/Business Analyst works with. For the proposal, the following types of standard requirements types have been defined:

  1. Business Requirements are higher-level statements of the goals, objectives, or needs of the enterprise. This describes such things the reasons why a project is initiated, the things that the project will achieve, and the metrics which will be used to measure its success.
  2. User Requirements are statements of the needs of a particular stakeholder or class of stakeholders. This describes the needs that a given stakeholder has and how that stakeholder will interact with a solution. User Requirements serve as a bridge between Business Requirements and the various classes of solution requirements.
  3. Functional Requirements describe the behavior and information that the solution will manage. This describes capabilities the system will be able to perform in terms of behaviors or operations – a specific system action or response.
  4. Quality of Service Requirements capture conditions that do not directly relate to the behavior or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the systems must have. This is also known as non-functional or supplementary requirements.
  5. Assumptions and constraints identify aspects of the problem domain that are not functional requirements of a solution, and will limit or impact the design of the solution.
  6. Implementation requirements describe capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to the desired future state, but that will not be needed once that transition is complete.


The deliverable from this effort is the scope statement and supporting information defining the following components by inclusion or reference. This proposal documentation is input to determine the development efforts, and includes the following elements.

  1. Summary of activities the led up to the recommended solution including the business environment analysis and competitive analysis.
  2. Strategic alignment describing how the initiative fits with organizational direction or mission.
  3. Business objective(s) and high-level business requirements.
  4. Product description and scope.
  5. Project boundaries including context diagrams to provide a visual model of the scope of the project.
  6. Assumptions and constraints.
  7. Major project milestones, funding requirements and limitations.
  8. Initial project approach including resource requirements, methodology, tools, and training requirements.
  9. Current and future standards, policies, regulations to be adhered to and impacts to the initiative.
  10. Commercial Off-the-Shelf (COTS) packages available vs. customized development of the solution.
  11. Dependencies, including downstream systems, interfaces, supporting data required.
Pre Sales, Software Services

What is proof of concept?

A proof of concept or a proof of principle is realization of a certain method or idea(s) to demonstrate its feasibility, or a demonstration in principle, whose purpose is to verify that some concept or theory is probably capable of being useful. A proof-of-concept may or may not be complete, and is usually small and incomplete.

In software development, proof of concept (abbreviated PoC) is often incorrectly used to describe three processes with different objectives and different participant roles. These uses of the phrase proof of concept are therefore not synonymous and are delineated below.

  • A proof of concept can refer to a partial solution that involves a relatively small number of users acting in business roles to establish whether the system satisfies some aspect of the requirements.
  • By contrast, the objective of a proof of technology is to determine the solution to some technical problem, such as how two systems might be integrated or that a certain throughput can be achieved with a given configuration. No business users need be involved in a proof of technology.
  • A pilot project refers to an initial roll out of a system into production, targeting a limited scope of the intended final solution. The scope may be limited by the number of users who can access the system, the business processes affected, the business partners involved, or other restrictions as appropriate to the domain. The purpose of a pilot project is to test, often in a production environment, whether the system is working as it was designed while limiting business exposure.

Why we need proof of concept?

A PoC generally should be done early in the development cycle or to sell a software concept. It is used to validate technical feasibility, helps identify potential stumbling blocks, identifies what a platform can or can’t provide, helps determine the scope and level of customization necessary to complete the project.

The PoC can also help identify performance issues.  Generally, today, we assemble many of our applications / solutions in a “composite” fashion.  We’re re-using services, functions, etc. from other applications.  This re-use requires integration points.  It’s these integration points in our overall “context” that we’re vetting with the prototype effort.  While also validating assumptions regarding what the platform or framework can or can’t provide.

The outcome is a technical feasibility confidence factor along with factors that impact overall scope and estimate of effort.

Effective PoC

To create an effective PoC we need to create a PoC project as well as a document which will cover all the technical, functional approach of the project.

Below are the useful tips to create an effective PoC project:

  • Create the same architecture for PoC project which you are going to use for the development.
  • Design a Login page with exciting graphical interface if security is a primary concern for the project.
  • Home page with logo, all the possible menus/tabs, Search, links for the other sub functions of the project.
  • The home page should speak about the entire site what we are going to achieve.
  • If the content of the home page or other pages is based on user Roles then you should develop different pages showing how it will look like after login depending upon Roles.
  • Dashboard if required.
  • One or Two pages/modules which will show that how you are going to design/develop the pages/modules and how they are linked to each other. These page(s) should be the most important parts of the application.
  • If the project has any report(s), create a sample report with exciting look & feel so that the client can understand how you are going to produce the results.
  • If the project has any graph(s), create a sample graph.

In brief, it should cover all the features in short so that one can see what you are going to achieve after in the production version of the project.

 How to create PoC Documentation

The documentation for your PoC should explain about the entire design of the project. You add the below points with brief description.

  • The architecture detail which will be used for development.
  • Add all the technologies, third party tools you are going to use, with explanations why you have chosen the same.
  •  Add all the modules with brief functionality which will be developed.
    • Add the methods how you are going to handle security.
    • Explain each menu you have used in the PoC project.
Methodology, Pre Sales, Software Services

Extreme Programming

Similar to Scrum, XP (Extreme Programming) starts the process by creating a backlog of work to perform during a sprint/iteration. XP creates the backlog by working with customers and creating user stories. In parallel with this work, the team performs an architectural spike, during which they experiment with the features to envision the initial architecture. XP classifies this work as the exploration phase.

The planning phase follows exploration. This phase focuses on identifying the most critical user stories and estimating when they can be implemented. Tasks are defined for each feature, to aid with estimating complexity. The team outlines an overall release schedule, with an understanding that a high level of uncertainty exists until the work begins. A release will have one to many iterations, which are typically 2- to 4- week construction windows.

When an iteration begins, the specific plan for the iteration is revisited. The team adds any new user stories and tasks that have been discovered since the overall release was outlined.

XP integrates customer testing into the development iteration. The customer is asked to identify the acceptance tests, and the team works to automate these tests so they can be run throughout the iteration.

The planning phase is followed by the productionizing phase, during which the code is certified for release. Certified means the code passes all customer tests plus nonfunctional requirements such as load testing, service-level requirements, and response time requirements. You can see an overview of XP in below figure.


Some of the characteristics of XP are as follows:

  • Specific practice —Unlike Scrum, XP is specific about the practices that should be used during a software project. These practices include pair programming, TDD, continuous integration, refactoring, and collective code ownership.
  • Modeling —XP teams frequently use modeling to better understand the tasks and architecture needed to support a user story.
  • Simplicity —Teams perform the minimum work needed to meet requirements.
  • Automation —Unit and functional tests are automated.
  • Quality through testing —Features are tested constantly, and developers check each other’s code via pair programming.

These are some of XP’s strengths:

  • Customer-focused (it’s all about user stories)
  • Quality via frequent testing
  • Constant focus on identifying and delivering the critical user stories
  • High visibility on project status
  • Great support for volatile requirements

It also has weaknesses:

  • Need for team maturity —Practices such as pair programming and TDD require responsible developers, and they aren’t always easy to obtain.
  • Dependency on testing —If developers know that significant testing will take place downstream, they may be less than diligent when they’re creating designs.
  • Scalability —XP may not work well for large projects.
  • Dependency on team member co-location —The team usually has a team room.

XP supports many of the critical goals of an agile process, such as dealing with volatile requirements and delivering prioritized, working software as soon as possible. XP also supports the principle of just enough, keeping with the lean philosophy of minimizing waste.

XP has sometimes been criticized for its lack of formality in system documentation and system design. In recent years this has changed, and XP teams now create the documentation needed to support a project’s customers.

Pre Sales, Software Services

Creating effective Information Architecture in 11 steps

Information Architecture (also known as IA) is the foundation for great Web design. It is the blueprint of the site upon which all other aspects are built – form, function, metaphor, navigation and interface, interaction, and visual design. Initiating the IA process is the first thing you should do when designing a site. Clients sometimes view the development of an IA to be impractical, both in terms of the time it takes and the skill needed to do it effectively. But this mentality is slowly changing. A good IA is incredibly effective, and knowing the basics of the IA process can save both time and money in the long run.

The following steps define a process for creating an effective information architectures.

  1. Understand the business/contextual requirements and the proposed content for the system. Read all existing documentation, interview stakeholders and conduct a content inventory.
  2. Conduct cards sorting exercises with a number of representative users.
  3. Evaluate the output of the card sorting exercises. Look for trends in grouping and labeling.
  4. Develop a draft information architecture (i.e. information groupings and hierarchy).
  5. Evaluate the draft information architecture using the card-based classification evaluation technique.
  6. Don’t expect to get the information architecture right first time. Capturing the right terminology and hierarchy may take several iterations.
  7. Document the information architecture in a site map. This is not the final site map, the site map will only be finalised after page layouts have been defined.
  8. Define a number of common user tasks, such as finding out about how to request holiday leave. On paper sketch page layouts to define how the user will step through the site. This technique is known as storyboarding.
  9. Walk other members of the project team through the storyboards and leave them in shared workspaces for comments.
  10. If possible within the constraints of the project, it is good to conduct task-based usability tests on paper prototypes as it provides valuable feedback without going to the expense of creating higher quality designs.
  11. Create detailed page layouts to support key user tasks. Page layouts should be annotated with guidance for visual designers and developers.

Developing an information architecture in this way enables you to design and build a system confident that it will be successful.

It simply isn’t good enough for organizations to build functionality or write content, put it on their computer systems and expect people to be able to find it.

Developing effective information architecture is an essential step in the development of all computer systems.

Effective information architectures enable people to quickly, easily and intuitively find content. This avoids frustration and increases the chance that the user will return to the system the next time they require similar information.

Remember: “People can only appreciate what they can actually find”

Pre Sales

12 tips for writing a winning proposal

The words “send me a proposal” are music to the ears of many consultants. The invitation to write a proposal is a milestone in the sales cycle — an opportunity to get one step closer to a client and a new project. Even though they might not really enjoy writing proposals, most consultants jump at the chance because they believe that exciting, lucrative work might be right around the corner.
A great proposal can be decisive in winning a project, while a poor one can cause you to lose a project, even if everything else in the sales process has gone flawlessly. Follow these 12 tips to a write a killer proposal every time.

1. Create a powerful, but concise executive summary Decision-makers start with and focus on the executive summary, so create this section with that fact in mind. When writing the executive summary, assume that the reader knows little or nothing about the proposed project.
2. Quantify the results that the client can expect from engaging you Some consultants create proposals that overemphasize their consulting process and methodologies. Clients buy results, not tools or methodologies.
3. Be generous with your ideas You may fear that revealing your ideas about how to solve a problem during the proposal process could result in clients taking those ideas and completing the project themselves. In rare cases, that may happen. But you’ll have more success if you don’t hoard your ideas. Use them to show clients that your team thinks and approaches problems in creative and innovative ways.
4. Size does matter Keep your proposals as short as possible, while meeting the client’s request. Think quality, not quantity.
5. Focus on the client Many proposals begin with a long discussion of the consulting firm, describing its qualifications and history. Focus your proposal on the client’s needs first, and then describe your firm’s capabilities. Remember, clients care only about how you’ll address their issues, so show them how you’ll do that.
6. Beware of best practices The client may view your liberal use of “best practices” as a convenient crutch. Instead of relying on answers that worked for a previous client, find a blend of outstanding practices and innovative solutions that fit your client’s particular needs.
7. Be accurate If you are using client data to support aspects of your proposal, double-check and triple-check that information. It’s easy for facts to be misunderstood and misused in a proposal. You’ll risk turning a winning proposal into a loser if you present inaccurate data to the client.
8. Sweat every detail Watch for typos, use high-quality materials, and make sure that the right people receive the proposal on time.
9. Rewrite your resume for every proposal Highlight the skills in your resume that demonstrate your qualifications for the project at hand. A boilerplate resume is rarely up to the task.
10. Finish early Let your proposal sit for a day after you’ve completed the final draft, and then reread it completely before sending it to the client. You’re likely to come up with some new ideas that enhance your work, and you may find errors that you missed earlier.
11. Let your personality shine through Give clients a sense of your firm’s culture and its style of working. The traditional, stilted language of many consulting proposals doesn’t help clients answer the all-important question: What will it be like to work with these consultants?
12. Don’t let your claims outdistance your true capabilities Some proposals tout the expertise of the consulting firm by referring to past successes with similar projects. These testaments to past achievements are important, but be sure that the capabilities of the proposed consulting team can live up to your firm’s claims.

The proposal is a crucial step in the consulting sales cycle. Don’t trip by providing a misleading, sloppy proposal. Instead, engage your client with clear, thoughtful explanations about how your firm is uniquely suited to meet your client’s needs.