Preventing Project Failure

CLASSIFICATION: UNCLASSIFIED

CAVEATS: FOR DOD SOFTWARE PROJECTS LESS THAN $2 MILLION

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.

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.

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. 

• • Comments [3]
  • Tags [process]
  • Categories [Methodology]