Agile Manifesto:

Recently I read an article titled:

Considerations for Using Agile in DoD Acquisition

The article is an overview of Agile and how it may work within the Department of Defense and how it could be incorporated into a PMO setting.  Within the article there is a small part that mentions that the Air Force has tried Agile methodologies for a couple of small projects and they have come up with their own Agile Manifesto (here is part of it):

THE FIST MANIFESTO (Fast, Inexpensive, Simple, Tiny) 

System development projects should be done by the smallest possible team of talented people, using a short schedule, a small budget and mature technologies to deliver innovative solutions to urgent needs. 

This approach is called FIST: Fast, In-expensive, Simple, Tiny. 

Short timelines increase agility and stabilize requirements, technology, budgets and people. Short timelines also force accountability, ownership and learning. To maintain short timelines, a project must also exercise restraint over budgets, complexity and size. Increases to the project’s budget, complexity or size inevitably reduce its speed.

Accordingly, the FIST approach advocates the following: 

• Minimize team size, maximize team talent.
• Use schedules and budgets to constrain the design.
• Insist on simplicity in organizations, processes and technologies.
• Incentivize and reward under-runs.
• Requirements must be achievable within short time horizons.
• Designs must only include mature technologies.
• Documents and meetings must be short. Have as many as necessary, as few as possible.
• Delivering useful capabilities is the only measure of success.

Is On Time Often Over-rated?

Is delivering something on time more of a goal for most of your projects?

Many projects never set firm end dates because they understand that the project requirements may change throughout. When the project ends, typically past the original end date we celebrate! Right? Yes! Cake for everyone because we knew upfront the date would slide.

Now what about the project that has set requirements and you blow by your initial end date by months and the product is full of bugs? Cake for everyone! Why? The project needed to be completed and the lessons learned were that we didn’t have the right durations for the timeline.

Now what about an end date constraint? We hit the end date, but several of the requirements needed to be dropped to meet the timeline. Cake for everyone!

Many times on time is defined by the organization. Many organizations understand that dates may be pushed, or requirements dropped or added, or finished software may have bugs. If this is business as usual then you may be eating a lot of cake!

The true indicator is how risk adverse the sponsor is to a slipping timeline? They may be the first to market for a product so they may have a low threshold for slippage. Or if they are building a software package that is a must have for the business, but they have an older system in place that is working fine, then they may have a higher threshold for the timeline to slip.

How do we control this slippage? Make sure you have all of the right stakeholders at the start to define the requirements and build the timeline. Bonus structure. I’ve seen and have worked for organizations that have given a bonus to the PM (and sometimes other stakeholders) for meeting a milestone like the end of the project on time. Communication!  Remember 90% of managing a project is communication.  Or you can “Let them eat cake”!

Related links:
http://pmtoolsthatwork.com/does-anyone-care-if-your-project-is-on-time/

http://pmtoolsthatwork.com/is-your-project-on-time/