How Scrum supports the Software Development Life Cycle

Last month I did a blog series on the importance of having a well define Software Development Life Cycle. Today I am going to talk about a methodology which supports the Software Development Life Cycle to keep it on track and humming.

Scrum is an iterative software development framework that employs time boxed “sprints” to deliver software quickly and incrementally. Scrum’s short development cycles offer flexibility to react to change by demonstrating functionality at the end of each iteration, promoting frequent customer interaction, and having the customer as part of the team. Scrum is used for larger efforts where work can be prioritized in batches, with each batch being of a scope and complexity such that it can proceed uninterrupted.

A Scrum team is made up of a number of players with differing roles and responsibilities.

Roles
Responsibility

Scrum Master
Enforces adherence to the Scrum methodology. Responsible for removing impediments for the Delivery Team. Ensures project objectives are met while balancing constraints, budgets, schedules, resources, and risk.

Delivery Team
Responsible for delivering the work. The team is made up of the following roles:

Product Owner: The voice of the customer. Has the responsibility to deliver a successful product in terms of vision and features. The  Project Lead would be the ideal person to fill this role.
Requirements Manager: Elicits, refines, and manages the solution requirements
Architect: Defines the architecture and technologies employed by the software solution
Technical Lead: Oversees software design and development
Developer(s): Codes and integrates the software
Software Test Engineer(s): Validates the software against solution requirements; enforces applicable quality standards and documents identified defects
Configuration Manager: Stages and deploys software changes to Development, Staging, and Production environments
Data Architect: Defines data architecture and allocation of data assets
Database Administrator (DBA): Maintains database; manages data access, import/export processes, and migration […]

Part 4: Tera-Scope Contracts – Value Add or Gordian Knot?

In Parts 1, 2 and 3 of this series we have looked at the trend for Federal Information Technology (IT) procurements to enter into “Tera-Scope” contracts where all possible IT goods and services are brought under one massive Performance Work Statement.  Some Agencies are requesting all-or-none responses which are impossible for any one company to meet alone.  This adds further to the complexity by necessitating Teaming Arrangements that create groups capable of meeting all the task areas, experience requirements and socio-economic requirements of the RFP.  Some Agencies are creating their Tera-Scope RFPs but allowing companies to participate only in those areas representing their core competencies.  This simplifies the proposal writing process for the contractor and the evaluation process for the Government.

Ultimately a set of contracts will result that can be used by the target customer groups within an Agency, or even Government-wide, for ordering.  In Agency specific scenarios, the resulting contracts are promised to be the only vehicles to be used for any Agency requirement.  Project Managers must work with a company or a Team that has one of the contracts under the Tera-Scope.  Work may be competed only among those companies or Teams that have one of the contracts under the Tera-Scope.  Let us hope the Source Selection Team has chosen wisely and avoided protests from the losing companies.

What does the Government believe will happen when it limits its buyers’ access to companies that provide goods and services?

Winning companies should provide better prices just because they know they are more likely to get work now that the competition has been narrowed (aka Strategic Sourcing).
Winning companies should continue to provide better and better prices because they have to compete within this smaller pool to […]

Part 3: Tera-Scope Contracts and Risk

In Parts 1 and 2 of this series we talked about the contractor and Government perspectives of setting up for, releasing and responding to a Tera-Scope contract opportunity.  Now let’s talk about the high risks associated with putting together such a complicated contractual arrangement.

For several decades the Federal Government has employed Long Term Contracts in order to found relationships with a vendor or vendors for a long period of time.  Task orders are issued against the contracts for work as needs arise.  This saves the Government from repeating the full acquisition process over and over.  Sometimes only the founding Agency can order from the contract.  If ordering is open outside the founding Agency it qualifies as a Government-Wide Acquisition contract (GWAC).   I’m calling a Tera-Scope contract a Long Term Contract where the Government combines every conceivable IT service under one umbrella that requires each offeror to respond to all task areas.  This necessitates Teaming in order to present an excellent proposal in every regard.  For Tera-Scope opportunities where you must respond to all task areas a company cannot afford to be “just okay” in any one of them.  The main difference for a Tera-Scope is that the range of tasks included is very broad – even vast.

In responding to a Tera-Scope RFP proposals must detail why a Team is high quality and high value for every aspect of the Tera-Scope.  Once everything is written and submitted it may still be a while before a decision is made by the Government.  A recently publicized Tera-Scope draft RFP comes with a timeline of 12 months for evaluation and selection of teams for award.  Make sure you understand the termination provisions of your Teaming Agreements. You don’t […]

Improve Cybersecurity with Continuous Monitoring

Cybersecurity has now superseded terrorism as our country’s #1 threat. Can continuous monitoring save the day?

Part 2: Tera-Scope IT Contracts

In Part 1 of this series we talked about the trend towards “Tera-Scope” competitions within the U.S. Government for comprehensive Information Technology (IT) services.  Here in Part 2 we will take a peek under the tent at what the Government is going through.

Many groups that are often perceived as different business areas have collaborated on the PWS for this Tera-Scope contract.  Contributions for task areas have to give enough information about that area to foster understanding of the possibilities without getting too specific about what work will or won’t be ordered, so there can be no perceived promises.  Someone should be reviewing the whole package for consistency, duplication and conflict resolution.  Often this is left to the contracting folks who are not technical experts.  The evaluation criteria must give clear guidance to offerors and evaluators on what the Government needs to know to choose the right Teams.  All of the RFP requirements are pulled into a very large package that undergoes a series of pre-solicitation reviews to make sure the RFP is coherent, compliant and will result in a contract that achieves the Government’s objectives.  It depends on the organization and on the specific individuals involved as to how much conversation takes place between the requiring activities and the contracting activity before the RFP hits the street.  More is better, but more takes longer and these days speedy contract awards are in high demand.  There can be a tendency for a “you take care of your part and I’ll take care of my part” scenario to develop between the requiring activity (the IT Department) and the procurement activity.  There are not too many more frustrating things than re-explaining your requirements to your contracts specialist after […]

Part 1: Is the Trend for Tera-Scope Terrifying or Terrific?

In this 4 part post we are going to explore a trend in how the U.S. Government is acquiring Information Technology (IT) services. More and more agencies are developing Performance Work Statements (PWS) with every possible type of IT service (including associated item acquisition) into comprehensive, umbrella arrangements. There are several variations on this approach but the most current one seems to be the “all inclusive package”. In Part 1 of this post we are going to look at how vendors perceive what I am calling “Tera-Scope” opportunities.
Old Way: The Government needs a specific set of IT services over a multi-year period of time that will accomplish one large overall objective (such as the full life cycle of a computer business system). Companies 1, 2 and 3 compete. Company 2 wins the contract. Company 2 hires subcontractors to fill capacity or skill gaps and begins working with the Government to achieve the Government’s objectives. Next month the Government needs another specific set of IT Services over a multi-year period of time (let’s say it’s Help Desk/Customer Care). Companies 1, 4 and 5 compete. Company 4 wins the contract. Company 4 hires subcontractors to fill capacity or skill gaps and begins working with the Government to achieve the Government’s objectives. And so on…., resulting in a lot of contracts to manage.

New Way: The Government writes a “Tera-Scope” Performance Work Statement (PWS). It covers every aspect of IT services and products including property acquisition and installation, facilities management, operations, software development and sustainment, systems engineering, technology assessment, information assurance, help desk/customer care, training, administrative support and the kitchen sink. Only winners of a contract will get work within the Tera-Scope from that Agency. Any of the […]

Google+