Preventing a Meltdown in 1787 OR How Courageous Scope Management Saved your Fireworks

This is a reprint of a post I wrote in 2009

As anyone who has read Howard Zinn’s Peoples History of the United States will tell you, there’s always a different way to view our history. For example, on a recent trip to Mount Vernon, I found out that George Washington died of a disease that slowly constricted his throat until he couldn’t breathe; in effect, he strangled to death.That still gives me the chills.

Anyway – since we are celebrating our national birthday on July 4, I thought it appropriate to think about how this country almost never came into being; through my rose colored Project Management glasses.

Ok so its 1787. Lets say that George Washington is the Project Manager for the ‘Create the United States’ project.In theory, George should be happy. After all, the project:

  • Had a clear vision and deliverables (Just for fun I created a Project Charter based off the Declaration of Independence)
  • Managed to mitigate some serious risk like losing the war and getting hanged.
  • Achieved its key deliverable, free and Independent colonies with a centralized government
  • Established ongoing change management process formalized in the Congress and the Articles of Confederation

And everyone was free to pursue life, liberty and the pursuit of happiness. Right?

Wrong. The reality on the ground was:

  • The national legislature, wandered aimlessly about the country, with no permanent home.Didn’t matter, cause barely any representatives attended.
  • States were bankrupt
  • Trade was dwindling
  • New England was thinking of forming its own country
  • Revolutionary war vets were donning their old uniforms and threatening to take over the government of Massachusetts.

Clearly, something wasn’t right.The initial set of requirements for the ‘Create the United States’ project were called the Articles of Confederation. And the Articles were failing; what was built wasn’t meeting the mark.The utopia envisioned in the project charter was a distant possibility, not a daily reality.

I just finished watching Andre Augusto Choma’s most excellent presentation at the PMI EMEA conference in May of this year where he lays out the Top 10 Ways to Kill a Project.  Number 1 is to Have a Vague Scope and number 2 is to Never Revisit the Scope.

I would argue that the Declaration of Independence was fairly vague when it came to how newly Free and Independent states would relate to each other.  Of course, there was pressure to act quickly so I imagine that a modern day PMP would attempt to raise the issue at the signing, probably would have gotten shot down and therefore would add a risk to the risk register something like:

Create United States Project Risks

Structure of Government and Interrelationships Between Governments Has Not Been Determined.

Lack of Clarity Around Future State Executive Decisioning.

And in fact the Articles of Confederation tried to deal with these issues, but produced a set or rules, rather than a mechanism for creating rules.

Further, lost in the Articles was the clear vision of Life, Liberty and the Pursuit of Happiness, the protection of which is implied but not clearly spelled out in the Declaration of Independence.

Knowing this, Washington called for time out.The project scope needed to be revisited.And the whole change management board (CCB aka The Congress) had to decide and approve a change, unanimously and collaboratively. In effect, the Constitutional Convention of 1787 was a really one massive CCB in response to one massive scope change request.

Sometimes Project Managers have to force the conversation, to shed the light on a problem and keep it on until the problem is fixed. Project Managers need to have the courage to be the force for change, and sometimes, to be the whistleblower. I’ve advocated for vision keepers in another post on this blog, and I would say that George Washington’s courage and actions during 1787 is the physical manifestation and examplar of that vision.

Seriously, let’s think about the ‘what if’. What if Washington took the CYA route on this one.He would’ve sounded something like this:

“Hey, you know, I didn’t sign the Project Charter or the Requirements Document, so I’m off hook here. I’m going to catch some fish.”

'Create United States' Work Brekadown Structure - Click /tap to see larger

I digress…Here’s how the CCB changed the scope:

  • The United States would not be considered a ‘league of states’.Rather the United States would be considered a ‘Union.’
  • Power would be centralized in a strong executive, a central Supreme Court, and a centralized legislature with a permanent home.
  • The centralized power would be limited by a series of checks and balances.

In effect, the old requirements were scrapped and new set, called ‘The Constitution’, were written.The original intent about life, liberty, defense, pursuit of happiness from the Project Charter was still there. But tellingly, the most important new requirement became the first sentence of the new requirements document.

“We the People of the United States, in Order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defence, promote the general Welfare, and secure the Blessings of Liberty to ourselves and our Posterity, do ordain and establish this Constitution for the United States of America.”

And the rest, as they say, is history. Thank God George Washington tenaciously mitigated for project risk. Thank God a solid CCB was in place to skillfully and honestly manage scope change requests.And Thank God for Rule of Law.

Have a great holiday.

“Create the United States’  Project Documentation

The Project Charter

My rewrite of the Project Charter

The First Requirements

CCB Meeting Minutes

The Second Requirements


Where Agile can be a hit in the Army Enterprise Or Data requirements Trump FRD

Caveat: This post assumes that the reader has a basic understanding of Agile software development. Here’s a primer if you need it.

There’s more than one type of App in the Army

Recently the Software Engineering Institute (SEI) teamed up with the DoD to explore the hurdles to Agile implementation in the DoD acquisition space.   Results were quantified in Considerations for Using Agile in DoD Acquisition which concludes that Agile is another method that could be used concurrent with a slight a re-evaluation of DoD 5000 acquisition guidelines.

My takeaway is that the authors could have a stronger case for Agile by targeting the correct space for the method within the DoD software application arena.   There’s more than one type of software acquisition in the DoD, and further decomposition of software acquisition types leads into a space that is golden spot for Agile to take off . My experience has been specifically in the Army enterprise, and so the focus of this post is the Army subset of DoD software acquisitions.

I'll get that app to ya...just as soon as I finish this FRD

I'll get that app to ya...just as soon as I finish this FRD

The Army is an enterprise that provides a product. That product is the manning, training, equipping and deployment of soldiers. But as an enterprise, the Army has the same enterprise needs as any other company; corporate accounting, IT Governance, business workflow, customer relations, business intelligence etc.

Army software acquisitions fall into two basic types; warfighting capabilities systems and enterprise management systems. Warfighting capabilities systems are referred to as Major Defense Acquisition Programs (MDAP). Acquisitions that support enterprise management are referred to as Major Automated Information Systems (MAIS). If a system is not considered to be Major, and designated as an MDAP or a MAIS, and is under $32 million then guidelines for software development milestones built into the Defense Acquisition System  (DoD 5000) process are significantly relaxed. In addition, acquisitions below $20 million are not required to produce earned value metrics.

And if the acquisition is procured as a service, the decision making authority for that acquisition lies within the department procuring the service. This results in independent departments purchasing IT application services from contractors for enterprise management and support; which includes workflow applications, business intelligence applications, and reporting applications.

The SEI article addressed acquisitions in general, with focus on Major acquisitions (MDAP and MAIS). However, I believe that software acquisitions can be further parsed into the following broad quadrants.

DOD Apps

The Golden Spot for Agile Development

Currently, there’s not a lot of oversight in space 2. In fact the Pentagon has recently come under fire for reducing contract oversight and I’ve written about the need for the oversight to expand into evaluation of software methodology as an audit function. Without oversight, and milestones paths, apps built in this space are inconsistent and highly dependent on the capabilities of the provider, rather than the needs of the users.

This results in a lot of Pain

Historically, at the mercy of contractors who may or may not adhere to global software standards, software applications in this space usually don’t handle data well, are hard to use, and don’t provide needed functionality that users need. I don’t have numbers for you, but I have been involved in legacy rewrites of these applications to bring them up to standard and I’ve heard and witnessed the pain these applications cause for the average Headquarters Department of the Army (HQDA) employee.

An Agile approach can solve for this pain because constant involvement of the user solves for inaccurate usability, design and functionality requirements. In smaller departments and on smaller projects, it’s easier to get a stakeholder to commit to daily scrum meetings. If not daily, at least weekly. Developers build directly from what the user describes, and work together with the user to release small modular pieces of software. This constant feedback loop ensures that the typical usability, design and functionality problems that emerge at user acceptance test get caught early and/or never become problems in the first place.

Is the FRD Necessary?

The government response to this pain has been to insist on documentation that proves there is some quality assurance process so that the communication pipeline from requirement through test doesn’t become a game of telephone. The Functional Requirement Document (FRD) proves that requirements are a) heard properly b) documented, and c) therefore can be properly tested. The Army Contracting Officer (COR) then feels that there’s some assurance that when they give requirements, the end result application will be somewhat close to what they described. Documentation also protects the government in case the application proves to be so bad that another contractor is bought in to take over, and needs to understand what the previous contractor built.

But the real issue is that the application is not meeting the requirements mark. Documentation in this regard becomes an arguing point, a contractual smoking gun that contractors don’t want to deliver until it’s absolutely perfect, and usually months after the build is released.

And in reality, Agile ideas developed out of this kind of pain. This is why one of the key Agile ideas is “Working Software over Comprehensive Documentation.” The question is, in the small enterprise software space, will the Army be able to accept working software over a comprehensive FRD? I believe that the answer is yes and, again, can be elaborated through decomposition, and this time in requirements. If we consider an average software application there are generally five types of requirements:

Usability Requirements – How the application feels

Design Requirements – How the application looks

Functionality Requirements – What the application does, and how it works

Data Requirements – What comes in and what goes out of the application

Security Requirements – Who can do what in the application

In general an FRD is supposed to provide functional, design and usability requirements that are elicited from the user, formally documented, and then passed on to the developer (traditional waterfall). In reality, requirements tend to change before the final FRD is complete. Up until that point, the FRD is in draft. And in fact, most contractors won’t deliver the final FRD until after the final build, to protect themselves contractually. What this means is that it’s often difficult to figure out what the true requirement really is. The FRD is almost never the accurate snapshot of what the application has become. Further, as an official deliverable, the Army pays for that documentation, and it can take months to complete an FRD.

So my argument is that the intent of the FRD is to ensure usable, working software.  Ensure working software with working software, not documentation.  Replace a heavy FRD with Agile daily scrums and sprint reviews, and development of smaller software increments that actually work as directed by the user and can respond to changing requirements.   Documentation of usability, design and functionality requirements is in the code, within the working version of the software.  Future developers who want to understand those requirements usually look at the code anyway, instead of the FRD.   Another idea to keep documentation light could be to ensure compliance to standards within the RFP.   For example, the COR could insist that the application adhere to USDA Usablity Guidelines.  That way the Agile team could create stories that reference the guidelines, without having to spend the time to writing the requirements themselves.

Data, however, is key. And I know a lot of sustainment contractors who would give their most treasured software manual for a comprehensive data model and dictionary of the application they’re taking over.  If documentation efforts are to be focused anywhere, focus where the Army really needs help – elaboration of data in data descriptions, data models and data interfaces. Better would be for the Army CIO to insist that all contractors follow the Federal Segment Architecture Methodology Logical Data Model guidelines.  That way, the templates and models would be fully elaborated in a consistent manner across all contractors.

Finally, security requirements are already written in Army Regulation AR 25-1  Army Knowledge Management and Information Technology and AR 25-2  Information Assurance and, again, should be better enforced by the Army CIO.

Removing the Documentation Hurdle

The SEI authors describe the DoD documentation hurdle thusly:

“…many Request for Proposals (RFPs) are written in such a way that a non-Waterfall response would appear to be or might be noncompliant. Most traditional RFPs require a full complement of Contract Data Requirements Lists (CDRLs) for documentation of progress. This level of documentation is contrary to Agile precepts of creating “just enough documentation”. Just enough will vary from situation to situation depending on the needs and regulation requirements of the project. In order for Agile to become common place within the DoD, the acquisition organizations should encourage, and contractors should provide, a compliant proposal with suggested alternatives that use Agile.” Considerations for Using Agile in DoD Acquisitions, page 13

In response, here’s my proposal:

1. Apply Agile to the right applications space.

2. In the right applications space, enable ‘working software over comprehensive documentation’ as follows:

a. Replace the Functional, Usability and Design requirements in the FRD with usable, working software built in collaboration with users

b. Document what is really necessary – Data Requirements

c. Don’t document security requirements, just reference and follow AR 25-1 and AR 25-2

Finally, it would just be great if a comprehensive set of guidelines for data documentation could be developed and enforced at the Army CIO level.  The FSAM is a good place to start.

Saturday Morning Rant OR Trophy Acronyms

I’ve been doing the contracting thing now since 2008. Meaning I’ve either been on a commercial-to-government or commercial-to-commercial contract as a member of the software provider team.

In this sphere I’ve met other like minded project managers; and we have secretly shared our horror stories about how things are just done wrong.

Acquisitions Officer accepts CMMI Level 3 apple from certified Big Integrator PMP. "Yes, YESSSSSSS My pretty!!!!"

Acquisitions Officer accepts CMMI Level 3 apple from certified Big Integrator PMP. "Yes, YESSSSSSS My pretty!!!!"

Personally I can’t tell you how many times I’ve been all excited to start working on a contract that fully employs Systems Engineering Technology (SETA) or CMMI level 2 or 3 environment only to be horribly dissapointed with the reality on the ground; places where questions like “can I see the change management process documentation?” brings blank stares, or tidbits like, a year into the project, “We haven’t baselined the schedule” is overheard.

I mean, people, why do we have methodology!? Why are we spending all this money to get people trained; we have ITIL, PMP, SETA, INCOSE, CMMI – Pick one! Lots of certifications flying around, and yet every time I take on a new project I always find the same sad story; a process in name only.

Here are some stories from my own experience and those of my buddies to chill your methodology bones, just before Halloween.

1. CMMI Level 2 Organization: An Integrated Baseline Review (IBR) on a project that doesn’t have a baselined schedule. How can you have an IBR without a baselined schedule?

2. Major System Integrator who advertises as a CMMI Level 3 organization: On a multi million dollar project, the baseline just keeps on moving. This is not – ‘oh we’ve finished so let’s plan the next iteration’, this is ‘oh-let’s keep moving the durations of the stuff we haven’t finished.’

3. Major System Integrator who advertises as a CMMI Level 3 organization, and whose PM had a PMP leaves a project with grade-school documentation. An application tied into senior level decision making has to have the functional requirements document, test scripts, configuration management, production support model all written from scratch by a new contractor.

4. Microsoft Gold Certified software reseller builds a system for clients without doing any business analysis because they don’t know how. They don’t understand what business analysis is. Client eventually sues.

5. PMP Director of Projects builds project reporting tool for a PMO based on sales; in other words, the projects are rated green, yellow, red based on how much the PM can upsell to the customer.

6. CMMI Level 3 organization pulls late nighters for a bid and ‘makes up’ their development methodology to win the bid, because they had not documented their existing methodology, then laughs about it the next day.

This is common. This is the reality. The organizations who are doing software development correctly are so few and far between that I suggested to a training organization that they train acquisition officers how to ask probing questions of contractors to see if they really take their methodology seriously.

This is most egregious in the public sphere. Acquisitions officers are getting hoodwinked by big and small organizations alike; sold on the acronyms and unable to discern truth from outright falsities. There are audit organizations that contractors are scared of – the dreaded Defense Contract Audit Association (DCAA) – for example, gets ’em shaking in their boots. But they only look at contracting and procurement, not software development methodology.

We need to expand the capabilities of audit organizations so they can  audit for truthfulness and soundness in software development methodology. Certifications are not an indicator of ability to produce good software and they are fast becoming trophies gained to win contracts, rather than assurance of organization’s commitment to good process.

Some References:

Glen Alleman is always a source of great content.  He points to the Open Process Framework’s list of common development  issues such as:

“Development organizations are not implementing the best industry practices and are sometimes even implementing known worst practices.”

Here’s some real life proof.  Lockheed has missed 19 of 32 requirements in EVMS reporting.  Read “Pentagon Action Against Lockheed Part of Larger Crackdown on Contractors”.

Glen lists all of the OPF issues on his post on problems that need to be addressed.

And finally, the Federal Contractor Misconduct Database tracks contract violations in government contractors. The good guys?  Mantech and MITRE with zero violations.

Fed Gov to get tough on Project Management Practices on Key Projects

July 28 2010: OMB Director Peter Orszag issues this memorandum with key points as follows:

OMB is “…launching an IT Project Management Reform”  by

OMB Cracks the Whip

OMB Cracks the Whip

  1. Halting the issuance of new task order for all financial system projects
  2. Setting forth new guidelines for project management for financial systems

These new principals will include:

“Splitting projects into smaller, simpler segments with clear deliverables”,  focusing on  “critical business needs first”, and conducting  “Ongoing transparent project oversight”


And starting now, “Agencies that have previously completed modernization projects must refrain from moving into additional rounds of planning and development until OMB has approved a revised implementation plan for those projects consistent with this guidance.”  And “..projects have to submit a self-evaluation and deliverables will be revised down to 90-120 days.”


The top 30 problem child projects will undergo rigorous review as part of a three step process described onOrszag’s blog:

First, New task order issuance is halted and new project plans must be submitted that adhere to the new principals.  Ie – Make em smaller, leaner, deliverable based.

Second, Fed CIO Vivek Kundra will evaluate the plans, and decide who will be part of the new budget. Ie – Some programs will get cut.

Third, OMB’s Jeff Zeints will present recommendations for new IT procurement and management processes. Ie – Failing programs will have new process/procedures to follow.

And let’s get clear with the problem children projects.  They are:

Department of Agriculture Web-based Supply Chain Management (WBSCM) $278.0 M
Department of Commerce BIS ECASS2000+ $64.5 M
Department of Commerce USPTO Patent File Wrapper (PFW) Program $276.5 M
Department of Defense Expeditionary Combat Support System (ECSS) $2.0 B
Department of Defense* Future Pay and Personnel System (FPPS) – U.S. Navy *
Department of Defense* Integrated Pay and Personnel System – Army (IPPS-A) – U.S. Army *
Department of Defense* Air Force Integrated Pay and Personnel System (AF-IPPS) – U.S. Air Force *
Department of Health and Human Services FDA MedWatch Plus $78.0 M
Department of Homeland Security NFIP Technology Systems & Services (2011) $101.2 M
Department of Homeland Security Homeland Security Information Network (HSIN) $473.4 M
Department of Homeland Security Automated Commercial Environment / International Trade Data System (ACE / ITDS) $4.5 B
Department of Housing and Urban Development HUD Transformation Initiatives $312.2 M
Department of the Interior Consolidated Infrastructure Automation Telecomm $7.6 B
Department of the Interior Incident Management Analysis and Reporting System (IMARS) $122.8 M
Department of Justice FBI Next Generation Identification (NGI) $3.4 B
Department of Justice FBI SENTINEL $556.9 M
Department of Justice JMD Litigation Case Management System (LCMS) $128.3 M
Department of Transportation En Route Automation Modernization (ERAM) $3.7 B
Department of the Treasury Consolidated Enterprise Identity Management (EIdM) $432.5 M
Department of the Treasury IT Infrastructure Telecommunications ITT TSS $2.8 B
Department of Veterans Affairs Benefits 21st Century Paperless Delivery of Veterans Benefits $579.2 M
Department of Veterans Affairs Medical 21st Century HealtheVet Pharmacy $163.9 M
General Services Administration Federal Supply Service 19 $376.2 M
National Archives and Records Administration Electronic Records Archives (ERA) Program $994.9 M
Office of Personnel Management Retirement Systems Modernization $136.0 M
Social Security Administration Citizen Access Routing Enterprise 2020 (CARE 2020) $599.3 M


First thoughts:

1. Hope it works.

2. Think that the new guidelines Jeff Zeints is prepping should incorporate lessons from the UK National Audit Office’s six reasons for project failure.  Specifically, separate intent from scope, emphasize communication over deliverables that represent communication, allow flexibility in contract scoping by describing the ‘what’ and not the ‘how’ in the contract.  Finally, remove the IMS as a contract deliverable.  Describe deliverables in terms of business capabilities, not project management deliverables.  A fancy schedule does not a project make.


Its Cognitive Processes, dummy! OR Three Steps to Think like a Successful PM

What’s missing from the PMBOK?


FM-5 The Operations Process

FM-5 The Operations Process

Don’t want to take my hippy new ager tree hugger word for it? Well, how about the US Army then?

I’ve been on Army contracts for a while now, though never served. So I was tickled when one of my ex-Army team members said I was like an Operations (Ops) Officer.

“Ops Officer? Really?”, I said, “What do they do?”

And he said with a twinkle in his eye, ‘Read FM-5 The Operations Process, you’ll love it.’

I’m a PM geek so anything with the word ‘planning’ it is is probably gonna make me happy but hey, I am really digging FM-5, which is the Army’s Operations Manual geared towards Ops Officers and commanders.

Back to visualization….Well, not just visualization but another concept, situational understanding, is new for me, actually.

“1-18. Situational understanding is the product of applying analysis and judgment to relevant information to determine the relationships among the mission variables to facilitate decisionmaking (FM 3-0). As commanders develop their situational understanding, they see patterns emerge, dissipate, and reappear in their operational environment. These patterns help them direct their own forces’ actions with respect to other friendly forces, civilian organizations, the enemy, the terrain, and the population. While complete understanding is the ideal for planning and decisionmaking, commanders accept they will often have to act despite significant gaps in their understanding.”

So think about that from a PM perspective. PMBOK trained PMs think in terms of Process and Knowledge areas, but this gaining situational understanding is a cognitive process; a way to think. FM-5 promotes mentally pulling together the whole situation, and then with all the pieces still forming in your head…FM-5 encourages a leader to visualize.

Another excerpt from FM-5

“2-53. Commander’s visualization is the mental process of developing situational understanding, determining a desired end state, and envisioning the broad sequence of events by which the force will achieve that end state (FM 3-0). First, commanders understand the conditions that make up the current situation. From this understanding, commanders next visualize desired conditions that represent a desired end state. After envisioning a desired end state, commanders then conceptualize an operational approach of how to change current conditions to the desired future conditions.”

To reiterate – these are all cognitive processes – ie, mental, in your head, ways to think, before you’ve done anything.

  • Synthesize the facts – gain situational understanding.
  • Visualize the end state.
  • Develop a mental concept about how to operationalize the desired end state.

THENdo stuff.

I just think that’s cool. And, on a the real, I could see these three steps laced throughout the Initiation and Planning Knowledge Areas in the PMBOK, or at least, given as guidance in the PMBOK guide.  For me, adding cognitive processes could be a big win for the PMBOK.

Why I think Agile is the Best Methodology for Small Software Projects for the Army




My Dad, Eddie Bonarek, in Vietnam

Its been a very sad week for the Army.  I’ve been working around soldiers now for about a year and I have to say that they have always impressed me with their intelligence, honesty and sensibility and  I’ve expressed this admiration right here on this blog.  My dad was a ‘nam vet and quite frankly never really overcame the demons from that era.   Just a regular guy from La Grange, a suburb out side of Chicago  – Eddie Bonarek was drafted in his 18th year and served as a medic.  We have this awesome picture of him, super buff, swinging an axe in barrack.  We all know it wasn’t that easy and war never is.   I don’t know what happened in the mind of that shooter in Ft Hood, and since I’ve never sacrificed myself for the sake of my country, I can’t say I ever will.

But I can damn well make sure that what I do for those who sacrifice themselves for me, is deliver quality.

Software developers working on Army contracts navigate a world of shifting political and contractual winds that can distract from the mission at hand. I’ve gotten swept away at times, and had to pull myself back into a ‘Boots On the Ground’ focus.  Its like we have to think of ourselves as blacksmiths of old, tinkering away at swords for warriors.  Imagine that into our shop one day rides the duke, and he wants the swords to have golden hilts, because of  mandate from the king.  So you start pulling out the gold, melting it down, until the next day, duke number 2 rides in and says ‘make those hilts in silver’ because he just heard the gold is not holding up in battle.  So then, you ask your shop owner to go and figure that out, while you sort of work on other things.  Your shop owner goes up to the castle, and works the court for a silver/gold solution which you start on right away, until the next day….

It can’t be helped really, its war.  And that’s the bottom line that we have to realize.  Any software shop worth their weight working on an Army contract should do some kind of enterprise analysis prior to diving into work.  I know this is not common practice, so I’ve done a bit of analysis for you software development folks, so that we can all grasp the magnitude of the difference between the Army environment and corporate America.

Analyzing the Enterprise I hear you:  ‘what the heck is enterprise analysis’   Let’s go there for a second.  Remember that future trends indicate that us IT people have to be well versed in the language of business to be muy successful in the upcoming years.  Gone are the days when we can just sit back and read O’Reilly books in peace; we have to understand WHY the business wants our software.   We do that through analyzing the ‘enterprise’, meaning the business as a whole.  It’s not enough to just understand that you have to build a widget.  You have to understand the business reason for the widget’s existence. This is how you stay competitive, how you understand requirements and how you deliver a product that meets the requirements. 

That’s why all the EA models always include an enterprise analysis.  Take the DoD Architectural Framework (DoDAF) for example.  The DoDAF encourages a three pronged view of any enterprise; first understand the Operational View (OV).    The OV is the ‘branch’ view; why the branch, say the Army, does what it does, how it does this – in other words, it makes you look at the operations of the branch.   In our blacksmith world, the OV would be something like ‘our blacksmith exists to provide swords to soldiers.  We get our business from the king, and sometimes the dukes.  We make armor too and a lot of horseshoes and we ship off weekly.’

As a techie, you’ll recognize the System View (SV) and Technical Standards View (TV) because that’s where we operate most of the times.  System View is about the tools created to meet the requirements of the OV.  TV is about the interaction of the tools.  SV is about the applications that exist and TV is about the technical architecture; networks for example.dodaf

But it’s the OV that rounds you out and makes you really valuable in any enterprise.  See, even in the DoDAF picture, the OV is on top, and I don’t think that’s a coincidence because both systems and technical standards are driven by the needs of the business, not the other way around.

Back to the Army So the Army has a unique set of operators that make it really different from corporate America.  Most contractors will recognize themselves in the blacksmith example above; requirements are constantly changing.  I think it’s important that we understand why, and better, think about the needs of our customer and respond to them in a way that’s flexible enough to handle what’s coming. 

Business Drivers and Competition

So here’s a bit of enterprise analysis to illustrate just how different the Army is from Corporate America.


Corporate America

Key business driver is to support the war fighter and protect the country key business driver is to make money
Threats are varied and unpredictable Threats(competition) are known, in a specific domain and operating under the same conditions as the company, therefore, more predictable
Rapid pace of change to accommodate rapidly changing threats Pace of change responds to broad market conditions, which have a slower pace of change.
President, the Congress, as board of directors are often publically and visibly at odds Boards of directors work to come to a united direction for the company

The Army has to respond to a set of constantly changing circumstances and, yes, it is life or death.  Threats come out of left field, mothers of soldiers call congress, and political direction changes according to who is the loudest voice this week.   Progress is what’s important.   A commander will routinely set a deadline to respond to business drivers.  She’s not going to consult the software team on how long it will take to make said progress.  So what often get’s sacrified is quality.

How to Manage Software Development in this Environment See, I’m thinking that our development methodology should in some way mimic the speed of the enterprise.  If they move fast, we should move fast.  And that’s why I’m now thinking that for small software development projects for the Army, Agile is the way to go.

And most business units in the Army don’t have business analysis capabilities in their shop.  They don’t have a person who can translate business to tech. But the agile method makes the whole team, developers, analysts, PMs, meet with the sponsor at the start of the sprint, and define a unique set of items to deliver through direct consultation and clarification.   A sprint planning session provides for the rapid elaboration of needs, something a BA would normally do through JAD or requirements sessions.  The developers hear it straight from the horses mouth so to speak.

Agile also addresses what I call Developers-in-the-Hole syndrome, which is developers disappearing into a hole  somewhere to build something only to surface months later with an app that does not meet the needs.  Again, you can’t develop in a hole in a rapidly changing environment…you will miss requirements.  And then you’ll get angry because the thing you’ve built and come to love will probably have to go through significant changes to accommodate rapidly changing requirements.

Don’t stay in the hole, instead, embrace the pace!

What about documentation, you ask?  Most contracts will require at a minimum functional requirements documentation and contingency documentation.  I say, do the documentation within the agile process.  You can certainly get in requirement document tasks, or contingency and coop planning during a sprint.  Sprints aren’t limited to just developer tasks.

Finally, some argue that quality is sacrificed in the agile process.  For example, If you build something this sprint, and it can change next sprint, you get into a spaghetti code situation.  Without the foresight of direction, ie some kind of software roadmap, you can get lost.  This is a valid point.  My response would be, figure out if your client has a policy roadmap on the business side.  Do they have a defined regulation that specifies their direction for the next year or two?  If so, their pace may not be as fast and you can slow down to think about longer iterations.

My reality My reality is that my team struggled this week with how to handle the rapid pace of change.   We are working through it with our customer.  I think we are going to wind up with a hybrid, smaller iterations, rather than big ones, and a standing Change Control Board which functions like sprint planning session.   I think that had I understood the environment a bit better a year ago, I would have encouraged an Agile method on a solid foundation of IT maturity methodology, from the start.  To me that would look like two paths of work for the team; an ongoing process improvement towards a higher CMMI maturity and continual Agile sprints.

BLUF (Bottom Line Up Front) Well, I’m giving you the BLUF at the end so I guess is now BLAE (Bottom Line at the End). But whatever, you know what I mean.   DoD contractors who manage small software development projects – let’s make it easier for our customer, let’s adapt to them proactively.  Let’s work to figure out the best way to incorporate changing requirements and give the boots on the ground the quality they deserve. 

Saturday Morning Soapbox – Thank God for the GAO

My army admiration has extended to the GAO because every piece of advice I have every written (ok so that’s not really a lot since I’ve only been writing for a few months) is here in this amazing pot of gold>>>>>  gao-bpr-guide.pdf <<Good Stuff Good Stufff

Honestly,  stop and don’t proceed further until you’ve read this guide.  If you are like me you’ll be nodding your head and talking to yourself saying ‘yeah’ and ‘right’ and ‘exactly’ and wondering out loud how the government can have such amazingly pure, simple, wise guidance at its fingertips and the rest of us didn’t know about it.   And I work on a government contract and I can bet that most people working on government contracts are not aware of the gold mine that exists, publicly, from the GAO.  But wait…there’s more!

Where have you been all my life????

Where have you been all my life????

I particularly like the Defense Acquisition University site which provides a clear path through visuals from the Clinger –Cohen act through Information Assurance, Business Process Reengineering, Portfolio governance and Management etc. on their IT Center of Practice site.

How to Use this Information

Understand what you are looking at:

The government doesn’t really invent things.  The government follows policy.  So this represents the set of rules and regulations that the government has to follow concerning how it implements and manages IT.    You are looking how the rules for how its done, the map, the set of instructions for IT.

Understand what this means to you:

This means that if you are working on a bid for the government or working on a government contract, you already have a clear set path to follow on your projects that you can reference with your clients to indicate why they should listen to you, and why they should implement what you are talking about.   This is the magic mantra that you reference as the reason for why they should follow you.  Your client doesn’t have to support compliance to private IT Maturity models like CMMI but they do have to follow the Clinger-Cohen Act and its directives around IT portfolio management.

So here’s a tip…learn this stuff.  And reference this stuff on, in and during your contract engagement.