Which Product Development Methodology Should I Use?

By Clay Shinn, Neubloc, VP of Engineering

This is not always an easy question to answer. Every client and project is different and has specific constraints that should be analyzed to determine an appropriate methodology or combination of methodologies to utilize. The best approach is to find the methodology that fits the clients' environment and will guarantee project success. Your outsourcing partner needs to work with you and not against. A partner who has too rigid of a process (or not enough) will not provide the product you want on time or within budget.

Neubloc's software design and development methodology -- Building Blocs -- is based on best practices that have been honed over many years on numerous customer engagements and internal product development projects. Our proven methodology increases our client's success by incorporating our clients' methodology and the best practices of CMMI, RUP, Agile and User-Centered Design.

This White Paper provides an overview of the Building Blocs approach and how we typically kick-off projects.

Neubloc's Building Blocs Methodology

Building Blocs has proven to be essential in order to meet challenging project needs as well as to ensure effective management over multidisciplinary teams from the U.S., nearshore and offshore - Neubloc's Rightshore approach. Our methodology allows us to work with you to determine the appropriate custom approach to your requirements. This will typically include the following phases; Discover, Define, Design, Develop/Test, Deployment/Maintenance. Neubloc's process has been designed to allow entry at any phase in your service or product lifecycle.

A well designed application must balance the needs of many diverse stakeholders while meeting the needs of a broad range of users from executives to task workers to customers. Our apporach utilizes the following principals:

  • Solid Management Practices: Successful projects do not just happen, they are created. In Neubloc's experience managing complex projects, we have found that a successful project outcome mandates the use of disciplined project management practices. A disciplined approach provides effective team communication and structure to maintain control and ensure that projects are completed on time and within budget. Every project and client is unique so Neubloc adjusts the Building Blocs management strategy to address the unique characteristics of each project.
  • Iterative Lifecycle Management: Successful management of software design and development projects begins with an accurate estimation of costs and schedules followed by efficient resource utilization and risk management to track specified delivery requirements. Neubloc's iterative management processes are flexible and has at its core constant project status monitoring, refinement and validation in order to ensure alignment with our clients' objectives.
  • Focus on Quality: Neubloc's number one goal is to contribute to our clients' success by ensuring high standards of quality throughout our design and development process. Quality Assurance engineers are typically involved in the early phases of a project to make certain quality is central to each effort. We utilize a number of quality tools in all of our projects including: user and technical requirements validation, usability testing, software test plans, test cases, code reviews and acceptance test plans.
  • Client Participation: Neubloc realizes and understands that application development is an iterative process. We propose a process that offers our clients numerous opportunities to review work progress. One of the key success factors to the Neubloc project management methodology is frequent communication with the client and scheduled client participation. We will work to establish project communication protocols to ensure participation throughout the project lifecycle.
  • Frequent Milestones: Neubloc believes in creating project plans that focus the team on milestones that occur at least every 2-3 weeks and will shift into Agile methods when appropriate. This assures that projects do not get off track due to miscommunication and other issues related to remote working environments.
  • Integrated Global Delivery: Every project that we undertake is staffed by a team with the appropriate skills and level of experience. Our teams are often global in nature allowing us to provide the right resources, at the right time, and for the right price. Our global teams are comprised of project leaders, architects, designers, usability specialists, engineers and testers who work seamlessly as a blended team, taking advantage of our U.S. and European locations to maximize the available daily work hours.
  • Integrated Delivery Process: The creation of any system should not just be approached from an engineering perspective, but should also address business and usability issues. Neubloc's overlapping cyclical phased approach ensures an end product that satisfies the requirements from all stakeholders and is adopted by end users.

The 5-Phase Neubloc Building Blocs is our methodology to creating systems and is based upon proven methodology such as the Carnegie-Melon's Software Engineering Institute's Capability Maturity Model (CM SEI CMM), Rational Unified Process (RUP) and integrates concepts of Agile programming where appropriate. Where Neubloc exceeds these models is how we incorporate user-centered designs and business consulting services with these traditional software development methodologies.

The diagram below is a high-level illustration of Neubloc's methodology. This is a tailorable, cyclical approach that utilizes a multi-disciplinary approach and team including, but not limited to; business analysis, user experience, engineering and quality assurance to ensure the successful deployment of a system and user experience.

At the beginning of a project it is imperative to determine which methodology will be used during the project. Neubloc and the client will dissect the Building Blocs methodology and the client own methodology to determine which processes, deliverables and tasks will be done and by whom.

High-Level Issues & Considerations to pick a Methodology

As a products design evolves certain aspects are sometimes overlooked. It proves helpful to resolve the following high-level issues when determining which methodology to use:

  • Clearly define the business objectives for the system (i.e. its purpose, its goals, etc.).
  • Outline in general terms what application capabilities and services will be required to meet the objectives. Note: One frequently overlooked capability is the need for the application to easily adapt over time as application strategy evolves and is refined.
  • Application users typically fall into groups with specific needs and requirements. Identify each specific application audience and define the specific needs and service objectives of each audience.
  • Analyze and document the way each audience must interact with the application to achieve its objectives. Note: This is a good point to begin considering and defining security issues such as access restriction requirements.
  • Identify and define the types of content and services that will be required to meet the objectives of each specific application audience. Consider how these services might need to cooperate and integrate to meet user objectives.
  • Consider the presentation requirements of content and services for both standard wired Web and for mobile clients.
  • Examine how application content and services are likely to evolve over time. Understand that management and users rarely know what future requirements will be. Develop a worst-case scenario of future requirements and services.

Neubloc's Project Kick-Off Engagement Model

The kick-off engagement portion of the Building Blocs methodology are the first two phases; the Discover and Define phases. Neubloc uses these two phases to set up projects to be moved offshore (if desired). For typical projects, these initial phases can be accomplished in 6-10 weeks. The diagram below illustrates which tasks and deliverables take place during each phase and what types of resources are typically utilized. Each of these task and deliverables are described in more detail in the following sections.

Typically teams are comprised of the following people during the first two phases of the project:

  • U.S. Based Project Manager: The US based Project Manager (PM) will help kick-off the engagement and will be the main point of contact for the client throughout the project. The PM will be responsible for managing the project, creating the project plans and assisting team members with the other deliverables. The PM is typically on the project close to full-time during phases 1 and 2.
  • U.S. Based Usability Engineer and/or Business Analyst: Depending upon the type of project, Neubloc will utilize a US based Usability Engineer and/or a Business Analysis during the first two phases of the project. This part of the team is focused on documenting the non-technical requirements, use cases and usability aspects of the new system. The Usability Engineer/Business Analysis is typically on the project close to full-time during phases 1 and 2.
  • Offshore/Onshore Technical Lead: The Technical Lead on the project typically comes from one of our offshore offices (if the plans are to move the project offshore). This person will work remotely during phase 1 and then will be on-site for phase 2 (or latter part of phase 1). This person is responsible for analyzing and documenting the current systems and working closely with the other Architects to design the new system. The Technical Lead is on the project full-time during phases 1 and 2.
  • U.S. Based Architects: Throughout the project, Neubloc will typically bring on one or more architects that have specialty skills to help understand the current system (if it exists) and work with the Technical Lead to architect the new system. These architect(s) are on the project on a part-time basis.

Discovery Phase

The main goal of the Discovery phase is to ensure that the end-user's, stakeholder's and customer's voices are not lost in the rush to build exciting technology. Neubloc focuses on gathering all the requirements -- from multiple angles. By the end of the Discovery phase, we will have the following documented:

  • The vision and scope of the project
  • High-level requirement for the new version of the product
  • A baseline assessment of the current system(s)
  • A high-level roadmap of where the company feels the product is going
  • A high-level resource plan, cost estimate and schedule for the remaining phases of the project

Each of these deliverables is discussed in more detail below.

Vision & Scope Document

The project will begin with Visioning Workshops to determine the future goals of the product and derive the critical success factors based on these goals. Neubloc facilitates a kickoff/stakeholder meeting and several 1-on-1 meetings to ensure a solid understanding from the various stakeholders. The result of these workshops also identifies the performance measures and the target environment that will be affected. This enables the design and redesign of business processes, culture, organization, information systems as well as, technologies, facilities, policies and competencies needed to achieve the goals.

The Vision/Scope deliverable will assure the business and technical requirements and project objectives/scope are properly captured and understood. During these meetings we collaborate with the client to:

  • Validate the goals, success factors and approach of the engagement
  • Identify the roles and responsibilities of Neubloc and the client
  • Identify risks and mitigation alternatives
  • Define high-level business and technical requirements of the system
  • Definition of end user groups

Baseline Assessment

The Baseline Assessment focuses on what currently exists in relationship to the product and its users. This assessment provides the team with a good understanding of the existing environment and provides a solid baseline for planning the products enhancements and direction. The Baseline Assessment will primarily be finished by the middle of the first phase. There will be updates to this document through the end of Phase One as all the requirements get documented. The Baseline Assessment includes a mix of engineering and usability analysis to determine some of the following elements of the existing environment:

  • Who are the current user groups?
  • What do they currently do with the product?
  • What else would they like the product to do?
  • What information do they currently use?
  • What information do they want?
  • How frequently are tasks performed?
  • What are the architecture and design constraints of the current system?
  • How does the current product perform?
  • What is the competitions product like? How is it the same and how is it different?
  • Who owns the product internally (engineering, marketing, etc.) and who are the other stakeholders?

The following tasks are performed in order to determine the answer to all of these questions:

  • User Profiles & User Needs Assessment
  • Technical Analysis of the current system (if it exists)
  • Current Content inventory
  • Heuristic Evaluation of the current system (if it exists)

User Profiles & User Needs Assessment

This step validates existing business requirements and uncovers potential gaps between what users want to do and what the organization believes the users want to achieve in the environment in which they will be using the product. The usability engineer evaluates the end-user audience to understand the demographic, psychographic, usage environment, pre-existing knowledge and the context in which the audience is completing the task at hand. The usability engineer uses methods such as contextual user profiling, task analysis and evaluation of constraints to better understand the audience to determine their goals and objectives for the application.

Technical & Architectural Review

Neubloc will perform a technical analysis of the current system to gain a baseline of the technical environment. The review process itself typically involves review of work materials, interactive discussion and development of deliverables. The review of work materials assumes the existence of artifacts from the design process; such as written documentation, code prototypes or other forms of documentation of the design that will provide the information required.

Interactive working sessions with a client's technical staff typically follow a review of these materials and can range from formal interviews to informal design discussions. Deliverables developed from the review typically include documentation of findings, risk assessment and recommended corrective actions.

The following are elements of system design that are typically reviewed by Neubloc as part of a technical design review. Any or all of the following elements may be reviewed, depending on the client's needs and the nature of the system in question.

  • Architecture Review - Business Alignment: Assessed by reviewing business and functional requirements and determining the comprehensiveness of the architecture in providing the capabilities required to meet those requirements.
  • Architecture Review - Technical Alignment: Assessed by reviewing system requirements such as scalability, availability, manageability, performance, security and determining the completeness of the architecture in providing the capabilities required to meet those requirements.
  • Architecture Review - System Integrity: Assessed by reviewing the system composition and organization for conformance to proven engineering principles and architectural patterns.
  • High-Level Design Elements: The following are elements of the design that are developed to fulfill specific capabilities of the system and which in most cases will result in the construction of corresponding physical software components.
    • Data Sources
    • Data Components
    • Business Components
    • User Components
    • Service Components
    • Deployment Distribution
  • High-Level Design Qualities: The following are qualities of good design that are referenced and validated throughout the review of the individual design elements. These include, but are not limited to:
    • Adherence to system architecture
    • Adherence to system requirements
    • Consideration of performance, maintainability, reliability, scalability
    • Consideration of security
    • Completeness of interfaces
    • Logical partitioning, coupling, and cohesion
    • Appropriate use of design patterns
    • Appropriate use of application framework capabilities (e.g. .NET, J2EE)

Current Content Inventory

Neubloc will identify all content that is currently being presented to determine what needs to be added, removed or edited, and migrated to the new system. This also assists in determining the future information architectures. Common information collection and documentation mechanisms are to identify all pages and document content (URL, page title, type, etc) on each page in a table and review web traffic reports.

Heuristic Evaluation of Current System

One of our usability experts begins by developing a list of usability heuristics that are relevant to a client's product and includes industry-standard heuristics. Those heuristics form the basis upon which Neubloc measures the entire product. The usability expert then walks through the product several times while performing user tasks.

As the usability expert works, (s)he notes the location and severity of violations of the usability heuristics and describes each individual issue and possible solutions in detail. Recommendations to improve the user's experience are identified as part of the review of the product, as well as captured in a global recommendations section of the document. The usability expert documents the results in a report that includes a summary of the product or site-wide problems and possible solutions as well as individual page's or product feature's heuristic issues.

Product Roadmap Analysis

It is important that everyone on the team understands not only the near term goals, but also where the company feels the product should be 1-2 years from now. Many companies use product roadmaps to provide these guide posts and are typically used to describe the overall strategy and direction of the product. The roadmap can comprise of many components and is not always kept up to date or is not used at all due to the rapidly changing environment the company/industry operates in.

If a roadmap exists, Neubloc will review the elements of the roadmap that will affect the products design and resource direction to make sure it is in sync with all other materials that are analyzed and created during the Discover phase. For most companies the roadmap should address the following elements:

  • Feature packs
  • Technical direction
  • Product philosophy
  • Target customers
  • Budgets
  • Release schedules

High-Level Requirements

Neubloc will use the requirements definition process in order to capture comprehensive high-level requirements that are described in the form of a hierarchy of functional areas and a high level description of functionality. Common information collection and documentation mechanisms are:

  • Document the functionality, performance requirements, technical information and data (purpose, input, process and output) needed for specific information about each functional requirement of the software
  • Define the required attributes such as security, maintainability, reliability, mobility and availability, not how that functionality will be implemented
  • The High-level business objective of the overall system is defined
  • User expectations regarding system quality are defined
  • Non-functional requirements such as business rules, external interfaces, platform constraints and capabilities and quality attributes are defined
  • Prioritize functionality

Resource Planning, ROM Cost & Schedule Estimations

Once the team has a good understanding of the product requirements and the client expectations, the team will put together the plans for the follow-on phases of the project. Phase 2 plans will be finalized while the estimates for the remaining phases will be estimated. The following elements will be included in the plans:

  • Resource Planning:
    • The types and skill levels of people who will be need on the project
    • The known hardware and software required
  • Cost Estimates:
    • A refined estimate to complete for Phase 2
    • A Rough Order of Magnitude (ROM) cost estimate to complete follow-on phases
  • Scheduling Estimates:
    • A refined schedule estimate for Phase 2
    • Suggestions for the types of development methodology that could be used on the project (waterfall, agile, etc.)
    • A preliminary schedule for the remaining phases

Phase 1 Findings Meeting

Neubloc will meet with the client to discuss the results and present the final assessment document(s). This is an informal opportunity to discuss impressions, conclusions and recommendations for ways to improve site or product structure and usability and to help kick-off the next phase of the project.

Defining Phase

After the Discovery phase, the team will focus on documenting how the new system will be used and what it will look like. By the end of the Defining phase, the following will be documented:

  • Detailed use cases of all the major tasks
  • Overview of the obscure use cases
  • Usability analysis of the new system
  • A high-level architecture of the new system
  • Project plans for the design and development of the new system

Each of these deliverables is discussed in more detail below.

Tasks Analysis & Use Case Mapping

In task flow analysis, the current information architecture is used to create a set of key use cases for frequently used features. Documenting use cases is a method of determining the flow of information from users to system (and from system to users), as well as the information precursors for launching a use case, the exception cases which must be handled by the system and the success criteria for completing a use case. Whereas the Information Architecture gives us a view of all system data and where it lives, the use cases give us a workflow for understanding what data is needed by users, how and when users can manipulate that data and how it is most intuitive to architect task flows.

The goal of creating use cases is two-fold:

  • The first goal is to organize the views into a cohesive and mutually exclusive set of tasks. This set of tasks normally morphs into the navigational mechanism of a task-oriented user interface.
  • The second goal is to give the development team a starting point for segmenting out their development tasks. Each use case maps to a specific user interface page/element/high-level object.

Usability Analysis & User Interface Concepts

The Usability Analysis will consist of identifying new content that needs to be added to the system and creating some User Interface (UI) concepts for the product that may incorporate the current Information Architecture, a user interface metaphor and primary tasks. Creation of the user interface design that complies with the organization's existing assets, design standards and the use cases developed. The conceptual designs are communicated via page wireframes. Wireframes suggest the page's content and controls and serve as a basic model of what the product may look like and how it will interact with the user; but does not detail aesthetic treatment such as font, color or other graphical elements.

New Content Inventory

New Content Inventory consists of identifying and defining the types of content and services that will be required to meet the objectives of each specific audience. Consideration of how these services might need to cooperate and integrate to meet user objectives and be easily updated to maintain freshness. If a current system content inventory exists, map the old content inventory to the new system to begin the content migration plan process.

Architecture Document

The Neubloc engineering team will next focus on creating a robust software/system architecture that handles all the designated "ilities" (backward compatibility, forward compatibility, extensibility, reliability, maintainability, availability, usability, etc.). Besides addressing the "ilities", the architect will focus on the following elements:

  • System architecture
  • Partitions all of the system's present and foreseeable software requirements
  • High-level data modeling

Project Planning Documents

The typical goal at the end of the Define phase is to have the project moved offshore. In order to have a smooth transition it is very important to have the following information documented and agreed upon by all parties:

  • Project Plan (schedule)
  • Cost Estimate
  • Resource Plan
  • Communication Plan
  • Agreed upon methodology concepts

Time, Cost & Resource Constraints

The team will create a Project Plan (Gantt chart) of the next phases of the project. The next phase will be detailed, while the following phase will be more high-level. The results of the Project Plans will be resource plans, cost estimates and projected schedules.

Project Communication Plan Document

A majority of problems on projects tend to be communication problems. Neubloc starts each project by working with the team to create a team communication plan and make sure that ALL members of the team (client and Neubloc) are familiar with the end result.

Outline what needs to be communicated:

  • How will information be communicated?
  • Who needs the information?
  • How often status reports should be sent (daily, weekly)?
  • What type of person-to-person communication will be utilized (Skype, IM, etc.)?
  • What happens if communication breaks down?

Neubloc will first establish communication protocols. Communication protocols can include rules guiding the use of different types of technology for different types of communication, who should be included in or informed of different decisions, meeting norms (in this case, conferencing behaviors and expectations), response times, acknowledgement of information received, etc. If your team crosses cultural boundaries, we ensure that these agreements respect those differences and don't favor one location.

Communication protocols should also address the need for "water-cooler conversations": the informal communication that occurs naturally in hallways and elevators - unless your hallways and elevators are miles apart. The antidote to that separation may be a rule that you begin or end meetings with a few minutes of chitchat or you may want to launch a chat room on your intranet.

The other key part of the communication plan is to document the meetings that the team will be required to attend. The meeting plans should include the following:

  • Who needs to attend?
  • When are they needed?
  • What will be thier purpose?
  • In what format will they be held (IM, video conference, web conference, teleconference or a combination of methods)?
  • Who will run the meeting?
  • Who will be responsible for publishing the outcome of the meeting (meeting minutes)?
  • Who will be sent meeting minutes outside of the attendee list (if any)?

Choosing a Methodology

Now that all the known requirements have been documented, the project can be structured in several ways. The decision primarily depends on the time-to-market goals of the customer, the rate of expected requirement changes and the general philosophy of the customer. The following are general methodologies the team may adopt:

  • Classic Waterfall: The client feels they have a very good understanding of what is needed for the next version or two. There is not a major rush to demonstrate something to the market. Or there is a lot of features that all need to be in place for the system to work.
    • Design everything we know of the system up front
    • Use slightly overlapping Design/Developer/Deploy phases using waterfall release cycles of 6-8 months
  • Modified Waterfall: The client knows at least the primary features of the next version, but moderate requirement changes (20-30%) might occur during the development. Or there is a moderate rush to demonstrate the next version to the market.
    • Design top 50-60% of system up front to allow the development to start and then continue to finalize the design
    • Use overlapping Design/Developer/Deploy phases using waterfall release cycles of 3-6 months
  • Incremental/Agile Development: The client requirements list will probably change often during the development or there is rush to demonstrate the next version to the market.
    • Design top 30-40% of system up front in order to have the main framework of the system in place
    • Start with an initial Design/Development cycle of 2-3 months to get the baseline framework in place
    • Shift into a series of 2-4 week Design/Development cycles where the system could be deployed at the end of each cycle if necessary

There are other methodologies that could be utilized; Neubloc will work with the customer to create a process that is appropriate for the project.

Phase 2 Findings Meeting

Neubloc will meet with the client to discuss the results and present the final project documents. This is an opportunity to discuss impressions, conclusions and recommendations for ways to help kick-off the design phase of the project and start transitioning to the offshore team if that is desired.

Next Steps

At the conclusion of Defining Phase, the plans would be to move the project into the Design phase. This is also typically the point we begin moving the project to the offshore team (if desired). The team will begin to change as more engineers are brought on to help with the software design and the Business Analysis resource(s) reduce their hours to only reviewer status. The Usability Engineer will finalize the more obscure wireframes and work with a User Interface/Graphics Engineer to start working on the screen mock-ups.

 

For more information please contact:

Armando Viteri
CEO and President
Neubloc
Email: aviteri@neubloc.com
Phone: (480) 797-2970