The Degradation of Empirical Software Development Management Techniques

Today I went to the last lecture that concluded my foundational MBA course at USC (actually I am still in the lecture hall while I am writing this). The title of the lecture sounded intimidating: The Degradation of Empirical Software Development Management Techniques. Yikes. However extensive and unapproachable the title made the talk sound, it was actually focused on one major issue: while birthing and evolving software development techniques there has been a distinct de-emphasis on pragmatic metrics gathering. More and more it seems that people are concerned with the rhetoric and semantics revolving around an SDLC, rather than focusing on the SDLC management and aggregate end results to build practical reports off its garnished output. This loss is epic since it will result in the same mistakes being made twice.

I guess I can kind of see this happening in my own industry revolving around SharePoint development. There has been such stress placed on implementing one of the contemporary SDLC’s techniques like Agile and Scrum that people simple just enter into an auto-cliché mode when they are decided upon. Several companies who previously have had no development experience are somewhat forced to adapt, they haven’t had the need for such rubbish before because they had no need for custom software in general. However, SharePoint as a collaboration platform often times can work its way into such companies because information worker collaboration is a fairly consistent enterprise need regardless of industry. As a side note, I actually don’t know whether these are considered contemporary techniques ergo the placement of quotation marks around the term, I suppose in the terms of waterfall methodologies that seemed to be ingrained into management brains this is the case, so I will make that statement.

While I bring this point up, I am reminded of a short rant I had with a fellow MVP where this seems to be a quasi-proper place to insert it. In the realm of all of these new processes, we see even more to the metal of software development things such as ALT.NET etc. Quite honestly, I still follow my own paradigm which is DBAGDI, standing for Don’t Be a God Damn Idiot. In this methodology, you program how you want, and what your client expects of you. You solve a business requirement and move on. While some of these ideas and concepts spark some interesting debate whose output might result in a new way of doing things, and that’s neither here nor there, whatever happened to just programming well and within what a client expects, you know, being that metal bender programming guy that gets it done? Every day I swear I hear something new, ALT.NET, blah, blah, blah. I mean I work on a military installation, all I do all day is hear acronyms, then when I sit down to do my therapeutic development time that I enjoy so much that I made a fricking career out of it, more acronyms. Invading my space. Making me all sorts of mad. But ah, I digress from my original point which was more tiered around the project management space. Thank for hanging on through that.

Back to the project management end. While embracing and applying these SDLC’s into an organization, sometimes there is a distinct loss over what are often times required project management attributes. What’s the biggest one? Well, Earned Value Management (EVM) of course!

I am going to fly through this, but the work by Fleming and Koppelman pretty much defined EVM (it was in late 1998 if my notes serve me correctly, the professor wasn’t a historian :) ). EVM is a simple technique revolving around basic arithmetic, and likewise, provides uncomplicated, concrete metric output. EVM from a mathematical level is fairly easy to define, and is composed of several smaller formulas which are bloated and I will cover in a separate post how to simplify them.

Stepping back, let’s take a very basic, simplified look at Agile SDLC, and graft some of the major points out of it.

Agile is composed of short iterations, as opposed to large ones

Agile team members are self oriented, and the software development process generally include the entire team as opposed to chess piece management processes

Agile Is Adaptive And Expects Change

Agile Focuses On Highest Business Value First

Agile Lends Itself Well To Test Driven Development and Continuous Integration

There is a lot more but you get the idea, there are more resources than you can shake a stick at regarding Agile methodologies so I don’t want to cover it. The question remains, how do we integrate an Agile framework with some of these more formal project performance metric outputs? Furthermore, how can I compliment an adaptive SDLC that is an organizational preference with PM attributes that have been proven to provide central results?

It’s actually not that hard. Earned Value Management resolves around the Earned Value (which takes the Actual Percentage Complete by the Total Budget, simply APC% of TB = EV) and the Planned Value (which takes Expected Percent Complete Times Total Budget, simply EPC% * TB = PV). So, you calculate the Earned Value by taking your technical output against your planned technical output. Then, you can get your Planned value which is the technical output value constrained by a specific date.

Now this part is important, because managers think about one thing, dollars and cents. A lot of this value non-sense is, in essence, intangible. I say technical output because I didn’t take the note on the exact term that the professor used. You can’t put it into a monetary sense, and garnishing business value and trying to equate it at that is kind of self-defeating and in essence fictitious.

Now, let’s put these in some SharePoint terms to make some sense of it J SharePoint always makes things less complicated (sarcasm intended).

So, we have a typical SharePoint rollout at a Small-To-Medium enterprise whose initial project budget is $100,000 (hey, as consultants we always pad the cost a lil). Let’s not overcomplicate it and introduced varying development tasks and other nonsense.

In the Agile framework, we are separating this into short iterations, but for the sake of an example these are going to be a little broad. So, we are just installing SharePoint, them provisioning out some architected collections.

SharePoint task




Install SharePoint




Provision Initial Collections




Architect Site Structure






So, we got some of the basics down. Now, let’s do some project health indicators which can be feed into indicators at a later date, such as a Cost Performance Index (CPI).

First, let’s start off with the Estimated Percentage Complete. We are going to use our current iteration metric as the argument, even though there could have iterations before or after this index. So, I am going to start with the installation iteration, and see where we are at.

EPC (Estimated Percentage Complete) = CI (Completed Iterations)[5] / TI (Total Iterations)[15]

EPC = x = 33.3%

PV (Planned Value) = EPC (Estimated Percentage Complete)[33.3%] * TB (Total Budget)[100000]

PV = x = 33300

APC (Actual Percentage Complete) = TIC (Total Iterations Completed)[15] / TIP (Total Iterations Planned)[25]

APC = x = 60% Complete

EV (Earned Value) = APC (Actual Percentage Complete) * TB (Total Budget)

EV = 60% * 100,000

EV = x = 60000

Now, even though we have iterations, we can tell several things about our project even though we are just performing basic arithmetic operations. Most importantly, you are awesome because your Earned Value is above your Planned Value. You rock! If your Earned Value is less than your Planned Value, then you are in trouble.

Well, I think that covers basically what we were covering as far as empirical metrics are concerned. The point I am trying to drive home is implementing an SDLC is not a nice-to-have thing on any SharePoint project, it is required. And while this may be the case, it does not discount the tried and true project metric harvesting methods that have been around since the dawn of man. While producing of client deliverables is always the focus, generating valid project metrics can both help to manage your project better, as well as make sure that iteration problems that you have in one project, don’t get repeated on another.

Whew :)