BestPractice4_smaller

In order to successfully deliver any project or engagement a solid delivery approach should be employed. There are many delivery methods. At Codarex, we employ an Agile Development/Delivery Approach which is an application of Agile software development methods derived from the Agile Manifesto. We modified existing methodology to fit our delivery and deployment principles.

The traditional method to deliver a project or software is a sequential approach, very much like a relay race. In the general scenario, the stages are structured with each stage passing the baton onto the next stage only when their work is done. It all starts with a business issues discussion stage where the pertinent and high value business issues are documented. The business requirements are then delivered to an analytics and development team for the project stage. Finally, the results are delivered to the key stakeholders for consumption. This process is singular – passing the baton from one unit to the next with very little cooperation between the groups.  Under this delivery method, the risks are great that the final outputs will diverge from the business requirements document (requirements churn); take longer to finish the project (extended timelines); and miss meeting the expectations of key stakeholders and the company (increased cost burden).

The Agile methodology is traditionally described in terms of the play of a rugby team. Agile methods are a holistic method like a rugby team passing and moving the rugby ball up field as a team. Although the entire team is available for support, smaller groups materialize to move the ball up field, and passing the ball to another group when needed. This maintains forward momentum while keeping control of the ball. Agile methodologies generally promote a

  • Project management process that encourages frequent inspection and adaptation
  • Leadership philosophy that encourages teamwork, self-organization and accountability
  • Set of engineering best practices that allow for rapid delivery of high-quality software or outputs
  • Business approach that aligns development with customer needs and company goals

Conceptual foundations of Agile development are found in many methodologies including Scrum, XP (Extreme Programming), Crystal, FDD (Feature Driven Development), DSDM (Dynamic Systems Development), Lean Manufacturing and Six Sigma.

Codarex employs the Scrum Agile method for project management. The approach was first described by Takeuchi and Nonaka in “The New New Product Development Game“. It has been extended and documented by John Sutherland and Ken Schwaber with many resources available on the internet.
The fundamental concept of the Scrum methodology is the “sprint”. The project is divided into shorter unit-projects. Each unit-project is the basis of a sprint. At the end of each sprint, stakeholders and team members meet to assess the progress of a project and plan its next steps. The focus is on iterative improvements through frequent inspection and review by user reference groups. This allows a project’s direction to be adjusted or re-oriented based on completed work, not speculation or predictions.

More often than not, Codarex engagements have a software tool or solution as one of the project outputs. In designing and deploying software always “start with the end in mind”. Outlining the end goals at the very start of the process helps align resources and development.  For example, during the requirements gathering phase, it may be determined that certain metrics are required that currently do not have supporting data.  The end result would be to create a task to start collecting the needed data as soon as possible. Furthermore, employing Agile Software Development principles will help keep the software on purpose, on time, on budget, reduce risk, and ultimately increase final user adoption rates. Software design and deployment that misses the mark is wasted time, inefficient use of resources and irresponsible use of rare capital funds.

Our process includes the following components and corresponding deliverables:

  1. Business Issues Session
    • Deliverable: Business Requirements Document
  2. Teams
    • Deliverable: Resources with accountability on firm’s side and Codarex side
  3. Solution Design Documents
    • Deliverables: Data design document, Architecture design document, Systems Interface design document, and User Interface design document
  4. Project Plans
    • Deliverables: Project plans, sprint plans, scorecards, issues tracking methodology
  5. Project Outputs
    • Deliverables: Finalized documents, deployment, training, future development plan

We will examine these stages in more detail.

Business Issues Sessions

Want Want Need

Too often consulting and/or software projects are initiated without properly identifying, a priori, the business issues that the firm is trying to solve.  It is difficult enough to reach agreement or consensus on what the business issues are without the complications of the methods and tools to solve the business problems muddying the discussions.  Furthermore, the workplace is an ever-changing environment. Company resources will be promoted, will churn, or simply will be reassigned to more pressing matters.  Well written documentation is a record of intellectual property invested and it decreases on-boarding time for new resources or owners.

The sessions should start by defining the current state of your business problem and then identifying the future state with no consideration for how to bridge the gap. However, just documenting issues is not enough. It is important to identify the High Value Business Issues (HVBI) by considering the value associated with an issue: hard or soft ROI if available; issue expected lifecycle; impedances for solving the issue; and – arguably the most important – understanding key stakeholder’s sweet spots. Lastly, decide on what is a reasonable list of requirements that would meet your goals, meet the budget constraints, and adhere to time constraints. The issues can be grouped into logical phases.  A phased approach is typically embraced by all participants of a project, from capital allocation to user consumption of the final deliveries. The end result of these discussions is Business Requirements Document (BRD).

Teams

Control Influence Concern

In order to have successful projects, multi-disciplinary but self-organizing teams are required. But not all individuals have equal say. There will be teams that control and have ownership of the project.  There will teams than can influence the outcome of the project with their feedback.  Lastly, there will voices to which we must listen or show concern but who may or may not directly influence the outcome of the project.

The following teams should be established:

  • Executive Team, Project Team, Business Team, Technical Team – Control
  • Reference group for business requirements – Concern
  • User reference group for configuration review – Influence

The fundamental tenet is that the resources assigned to the teams are dynamically used.  That is, they are leveraged when needed and otherwise released.  The importance of Executive support for any project cannot be emphasized enough. Executive support should leverage all departments who are touched by the project.  In the case of software development, an IT executive will definitely be required, and of sufficient authority to bridge the gap between different groups within the IT department.

The Project team will consist of a project manager on both sides: both vendor and company.  However, the assigned project manager will typically have more than one project to manage.  Codarex, typically requests a second sprint project manager within the team.  The sprint project manager will manage the plans associated with each sprint and report to project manager lead as required.  For example, there may be monthly project update meetings with the entire team but weekly sprint meetings. The sprint project manager works closely with Codarex’s counterpart to keep forward momentum and align resources as needed.

The Business team is composed of analysts who understand the business issues. However, the business may also include representatives from other departments that the project impacts. Again the group self-organizes and enlists resource expertise as needed. In the case of pricing, the business team may be composed of, but not limited to the following experts: pricing analysts, product specialists, supply chain experts, regional directors, and/or sales representatives. The business team will own the business issues and have final authority over the business requirements.  However the business requirements documenting group will leverage different resources from different departments and end-user groups to provide a multi-faceted voice. These different groups will provide input but the Business Team will drive development and day-to-day operations.

The Technical team provides support for data requirements, system interface knowledge, and assigns necessary resources to perform the needed tasks. They bridge the gap between business terminology and IT terminology. The technical team would most likely be responsible for retrieving data.

The Reference Group provides input during the business requirements gathering phase.  Their role is to present additional information regarding their business units.  By listening to as many company voices as possible, we can limit the risk of missing crucial interactions.  For example, if we are delivering a dashboard system to the outside sales representatives, we would want to hear what inside sales may have to say.

The User Reference Group is specifically tasked with reviewing sprint outputs. They represent the “circle of influence” whereas the Reference Group represents the “circle of concern”.  Their role is to inspect and review the sprint deliverables and maintain a constant vigilance that the solution is delivering the desired result. The user reference group can be large as individuals with different expertise are requested to test different sprint outputs.  Codarex typically schedules review sessions with the entire group at points where there has been considerable development towards the final solution. This is to ensure that we do not lose sight of the forest for the trees – keep focus on the end goal.

Solution Design Documents

Solution Design

The BRD is translated into design documents that are used by developers to build the necessary tool set to solve your business issues. Project deliverables may or may not have a software component. However, business requirement documents and software design documents serve three purposes:

  1. Establishes the current state; identifies the future state; and itemizes the gaps to get there
  2. Forces inter-department teams to discuss the business issues together
  3. Gets multi-disciplinary and multi-department teams on the same page

The end goal is to reduce the risk of producing solutions that miss solving business issues and ultimately result in little to no adoption by users.

The Data Design Document (DDD) identifies the necessary data sources, data dimensions and data metrics.  Furthermore, it outlines any Extraction, Transformation and Loading (ETL) requirements.  For some projects there are external data sources that must be retrieved, cleansed and manipulated and used in the analyses and reporting. The data could be static, slowly changing and fast changing.  These attributes about the data determine the update frequency to avoid stale data.

The Architecture Design Document (ADD) documents any additions, change requests, or modifications that must be made to software systems. Typically projects are not changing fundamental IT architecture. However, projects have been known to drive IT infrastructure change or software replacement with a better solution. For Codarex, this specifically applies to our virtual appliances. For example, a customer may request that we install Windows Server OS instead of using the default Ubuntu Server OS in our appliance.

The Systems Interface Design Document (SIDD) identifies the data connection requirements for the data sources defined in the DDD. This description would include special technology, protocols, any specific message formats, error conditions, handshakes, initiation and closure, and other features that define the design of the interface. The end goal is to be able to connect to any required source and pull or push the needed data on a pre-determined frequency.

The User Interface Design Document (UIDD) provides a high-level description of the user experience with the project output solution.  The different user types and their corresponding security privileges are documented.  This could include access to different data, dimensions, and reporting metrics. It will addresses performance expectations and usability.

This level of document is both necessary and sufficient to ensure current support and plan for future growth.

Project Plans

projectplan_rescaled

Every project should have an over-arching project plan and assigned project managers from both the customer and the solution provider.  This represents the high-level summary of the project and how tasks will evolve over time to meet the project deadlines and stay within budget.  However the delivery of the project components will be carved out using Scrum Agile methodologies.  That is, the large project will be divided into manageable sprints that always have output to be reviewed.

The Business Requirements and Solution Design will be carved according to the following:

  1. Issues Tracking List
  2. Sprint Plans
  3. Scrum meetings
  4. Project Scorecards

It may seem odd to create an Issues Tracking List which is typically associated with delivered software. However, by translating the business requirements and solution design requirements into manageable issues to track, then it is easier to create the sprint plans.  The main principle behind sprint plans is small manageable iterations.  Typically they are 1 to 2 week development cycles with a maximum of 4 weeks.  The project team is charged with judiciously selecting Tracking Issues so that manageable small incremental gains are possible.  The Issues Tracking List also provides audit trails for that links development with the business requirements. At the end of each sprint is a scrum meeting to review what was developed. If any development fails then it is addressed in the next sprint plan. Lastly, project scorecards are an excellent method to keep the greater team appraised without the need for weekly meetings. The scorecard should be single paged with a quick reference for project status, any blocking issues raised, and current progress to date.

Project Outputs

The project outputs will be tied to the BRD and the SDD.  When all is said and done, the ultimate measurement as to the success and failure of a project is determined based on the quality, the quantity, and the timeliness of the deliverables that are provided at the conclusion of the project. Any documents must be finalized in a timely manner or risk losing important information.  Finalized documents will describe what is delivered and will become stable documents of record.  If software is delivered as a project output then it will have to be deployed to the entire user audience.  This will require training both for the super-users who will in turn help train the target audience.  Expect to have at least 3 training sessions in order to ensure user adoption success. Codarex supports 3 month intervals between training sessions.  Furthermore a method should be adopted to monitor user usage to evaluate adoption. The usage metrics will be instrumental in driving future development and even evaluating ROI.

Whether you employ Codarex, or you are simply applying our delivery principles, you can rest assured that you will be successful because our methodologies stand on the shoulders of giants (nanos gigantum humeris insidentes)!

General References