Thoughts on Enterprise Architecture and Project Management

Blog is Moving to Wordpress

As mentioned in my previous post today, I am moving the content of this blog to Wordpress. The new address for the blog is http://robertmcilree.wordpress.com

I will also be moving over most of the post from here over to Wordpress, and it will tke some time to do so as all of the 'easy' export functions I googled today don't want to take the entire load of posts for some reason. Thank god for manual cut-and-paste... :)

Thanks again for reading my stuff, and I'll see all of you over at Wordpress shortly!

 

Uncle Sam....Agile??

I subscribe to the free investigative reports generated by the United States Government Accountability Office (GAO). For my foreign readers and those not familiar with GAO, the agency describes itself as follows:

"The U.S. Government Accountability Office (GAO) is an independent, nonpartisan agency that works for Congress. Often called the "congressional watchdog," GAO investigates how the federal government spends taxpayer dollars. The head of GAO, the Comptroller General of the United States, is appointed to a 15-year term by the President from a slate of candidates Congress proposes."

GAO sends me email updates whenever they publish investigative reports in a number of categories. Imagine my surprise today when I opened their message about new reports in government information technology...

Software Development: Effective Practices and Federal Challenges in Applying Agile Methods. GAO-12-681, July 27.

Hmmm...I went to the site and downloaded it, and you can also with this link:

http://www.gao.gov/products/GAO-12-681

As the document is quite lengthy, including all of the boilerplate typical in government documentation, I will spend some free time over the weekend perusing the report and I'm fairly certain I will be posting commentary on it here in the next few days.

Agile government IT projects? Almost sounds oxymoronic, but I'll give it a chance and give you my take after I read it.

 

 

 

Measure What Really Matters

I ran across a very interesting op-ed by Tim Jackson on productivity today in the New York Times. The gist of his well-articulated argument is that due to our relentless drive for increased output, certain professions and their attendant tasks become negatively skewed because production and output are more important than outcomes. He cited medical practice and teaching as examples, and I believe that we can add enterprise, data, and solution architecture and project management to the mix.

His article and viewpoints resonated with me because over the past few years I have witnessed multiple incidents where enterprise, data, and solution architecture work was 'commoditized' by management and/or project leadership and results measured primarily by how much output (regardless of quality or usefulness) was produced in a defined timeframe. For example, I was a member of a project team designing a data warehouse where progress on the data model was measured by how many tables and table attributes were produced from business analysis documents per day - as opposed to examining this output with respect to it's clarity and usefulness to the database administrators and developers on the project team.

What the project manager failed to realize with respect to this effort is that there are multiple ways to judge the quality, usability, and completeness of a physical data model - the primary ones are correctly building and linking the model to the accepted/approved business analysis, adequate and correct linkage of related tables, ability of the physical model to be implemented in a database, and correct types and size of data. There are others, but these are the basics.

Instead this individual chose, incorrectly, to measure progress only by how many corresponding tables and table attributes were created in a given time frame. This led to an 'assembly line' mentality on the project where the project manager evaluated and treated the team akin to factory workers putting bolts into car frames as they pass by on the line. Not only was he not getting a true picture of where the deliverables stood at any point in time, but he introduced substantial risk on the project with respect to the quality and usefulness of the data architecture and models because he was only measuring gross output, not context or quality of the deliverables.

When this happens, astute project team members know how to play the game: if they are only going to be measured on gross output of work in defined time frames, and not completeness and quality, they'll simply produce as much crap as can be inserted into documents, spreadsheets, or modeling tools and they will meet expectations. Apply these 'methods' to software developers, and what is usually generated is lots of lines of code, but the developed 'system' may not work or have severe performance issues. Of course, it's going to matter later that such crap is flawed and perhaps unusable, but hey, they did meet mandated performance targets right?

Knowledge work cannot be managed, much less optimized on such crude and misleading metrics. While project timelines and deadlines certainly matter, there is a degree of subjectivity in knowledge work that cannot be adequately planned in advance, much less successfully evaluated with crude, misleading, and incorrect output metrics. Does your physician talk rapidly or ignore your comments during your examination, perhaps thinking about his patient load that day or some other issue unrelated to your care? How about your attorney, accountant, or dentist? Fredrick Taylor-style 'productivity' metrics when applied to such situations not only do not work, but they often severely impair real solutions and progress, in addition to being 'gamed' by astute project team members that adjust their work and output to what is being 'measured' with quality and usefulness of the work outputs being, in most cases, damned.

Knowledge worker outputs matter in terms of eventual positive results and outcomes moving projects forward, not in the measurement of minutiae per time increment.

 

 

Sins of the Project Manager

The current economic and employment environments notwithstanding, things still look pretty good for project managers. They are being kept on, and are still getting hired, because organizations are still ultra-cautious about spending money and getting critical projects completed as near to planned time and budget as possible. Salaries for PMs are continuing to be solid as well.

Which leads to the following dilemma, which shouldn't be surprising given the ongoing economic circumstances: everybody is now a project manager! Including a lot I have recently run into or heard about from colleagues that have absolutely no business being one, but they can talk a good game, at least initially.

In no particular order, here are some events and behaviors I have witnessed or heard about within the past few years that are clear signals the project manager involved was not skilled, have completely unrealistic expectations that medodology will always save the day, or had personal/character issues that precluded good-to-excellent performance on the job:

1. Narcissism. I have written about self-absorbed project managers in the past, and a recent experience with one (who ended up failing and getting terminated) leads me to firmly believe that this type of person has no business as a project manager. As examples, this individual: routinely made time and scope decisions on her own with no other inputs from sponsors, stakeholders, or project team members; always showed up 10-15 minutes late for meetings that she scheduled; sent e-mails to team members admonishing them to send responses directly to her, not to anyone else (and she then took credit for the team responses that she received with sponsors); when challenged about anything concerning the project, claimed that her way was 'Agile' when it wasn't even close; dismissed everything (no matter how reasonable) that conflicted with her point-of-view; and believed she was unaccountable to the team and sponsors for anything.

And those are just the highlights. This individual thought she was above all else not only within the project, but the organization. Luckily, it only took a few months for her to anger the appropriate people (she lost the project team within the first 2 weeks of her tenure) and she was summarily dismissed from the project and organization.

2.  Inexperience or insufficient experience. Granted, we all have to start somewhere, and project management is no different than other professional occupations and disciplines. However, PM is a skill-set acquired over time with experience and study - just calling oneself a PM when the position held was really "technical/team lead" or somesuch isn't usually enough to do the job properly. Lots of organizations screen resumes for PMP certification. That's OK to a point, but the resume had better list some significant real-world project management experience to be taken seriously, because I know people who hold a PMP certification that cannot explain what a Work Breakdown Structure is (for starters). Which tells me that while they are good at passing project management examinations, real-world experience is another matter entirely.

The downside is that the only way to spot a smooth-talker with insufficient or exaggerated experience is when the project executes. If it happens, cut your losses early and replace the individual with one who has actually performed in the position successfully in the past. You can evaluate this successfully in job interviews if you know what to ask candidates - ask about projects and how situations were handled, and not about certifications.

3. Control Freaks. These types come in various assorted flavors and I'll break-out variants of them below. The worst offenders second-guess (rather than constructively criticize) the work of the team and effectively stifle lots of hard work and innovation based on worldview, fear, and whims, as opposed to facts and experience. If you have a PM who forbids team members to utter or write any sentence or e-mail without pre-approval or editing, your project is in big trouble.

4. Second-guessers. Related to (3) above, but while PMs should have the basic non-PM technical foundation to manage projects (i.e. an IT PM with other relevant IT experience, a manufacturing PM with a manufacturing background, etc.), it is not necessary for a PM to be an expert on every technical topic, issue, or matter involved in a project. This is particularly true on large-scope projects, and that is why we have subject matter experts (SMEs) and highly-skilled members on the project team - to provide the necessary detailed expertise and work products.

However, there exists PMs who believe that they "know it all." This unhealthy behavior trait usually manifests itself in the instant negative feedback SMEs and team members receive when advising the PM of tasks and how long they will take (in effort and duration) to do. Most SMEs and project team members do a good-to-great job and give reasonable estimates, and their judgment should always be trusted by PMs unless facts over time dictate otherwise. If this principle is not followed, the PM will lose the respect and trust of the team, and the project will be compromised.

I usually allow one episode of second-guessing from a PM to occur before I react to it. If it happens again, I have a face-to-face with the PM and ask directly what problems he is having with the estimates. It will be even more directly put if the PM alters the estimates significantly or strenuously objects. Second guessers usually have trust issues, or the estimates that they were given were not what they anticipated or wanted to hear. Too bad....that's why we have project teams. And try as they might, second-guessers almost never change reality. What they should change, if they can, are their facilitation and leadership skills.

5. Command-and-Control Junkies. Another variant of control freak worth breaking out is the PM-as-Commandant. Sets up lots of rules and regulations for the project team, as well as 'enforcement' for the non-compliant. Also wants status reports in such detail that most of the project team's work week is spent preparing them. Fortunately, this type is easy to spot, and given the need-for-speed by business in the 21st century, easy to eliminate in most cases. They still crop up from time-to-time - particularly in government projects - so they are worthy of mention.

6. Tries to Manage People, not Projects. From my experience and observations, there are very few instances where members of project teams directly report to project managers. Usually, project management is a matrix function within an organization and team members have a manager that they directly report to, and the PM is the manager principally guiding outcome of the project, not direct supervision of team members. 

While effective PMs must have authority concerning project matters in addition to responsibility, people management - as in the supervisory kind - isn't usually part of the deal. PMs can certainly add or subtract people from the project team as needs and circumstances dictate, but day-to-day management of the people comprising the team is not in the job description.

Some PMs don't get this concept very well and believe that the team is at their beck-and-call for anything and everything. In such cases, the team members get confused because now they 'take 'orders' from two people - the manager that they report to, and the PM. And those orders often conflict with each other, making the problem worse.

Project team members have a number of choices in how to react to this, and the best move, in my opinion, would be to notify the 'real' boss/manager of the situation and let them handle it with the PM - that is, after all, part of what they get paid to do. The worst move? Telling the PM off, that you don't report to him, and he can kiss your posterior if he doesn't like it, ad nauseum. Use this only as a last resort if your real manager doesn't respond. Why? It can be really damaging to the team (especially if others are doing it also), and unless you really enjoy working on low-morale projects with a lot of gossip, rumors (none of them good, by definition), and backstabbing, this only puts more gasoline on the raging project fire and solves nothing - for anyone.

7. Lack of Transparency. One of the worst things a PM can do, short of outright lying about project status, is to make it very difficult for anyone to assess where the project really stands in terms of deliverables, budget, and schedule. Once that happens, credibility is usually lost with sponsors, major stakeholders, and the project team, which makes it almost impossible for the PM to continue on that project. 

If and when things go wrong - and they inevitably will at some point on any given project - three things matter: 1) assess the problem and impact; 2) provide a solution; and 3) implement the solution. This is Basic Risk Management 101. However, some PMs are so afraid of any damaging or potentially-damaging facts leaking out that they go to great lengths to destroy, hide, or distort such information - perhaps in the blind and often misguided hope that 'things will get better' somehow. Or, as is common with the various forms of control freakery, hiding the truth so the PM does not look as inept as he really is.

8. Embracing Alternative Project Management Methodologies as Fads - or Worse. There is no question that alternative project management methods such as XP and Scrum have taken hold in our world. After 10 years, Agile methodologies have matured to the point where many organizations have successfully used these methods to deliver projects. The problem here is two-fold: PMs who claim they are running an Agile project when in fact they aren't; and PMs who mix Agile/incremental delivery methodologies with older sequential ones like waterfall unsuccessfully (the latter case goes by such derogatory terms such as "Scrumbut," "Cragile," and my current favorite "Water-Scrum-Fall").

The first case is easy to spot as the PM continues to rave about "being Agile" and "we're Agile" and on and on to give sponsors and management the appearance that the project will be completed much faster than it actually can be. Usually while they are waiting for requirements and many scheduled meetings (over weeks) with the business and business analysts to get project requirements completed and signed-off. Then, because they are "Agile" - some miracle will occur that will deliver a complex project in an absurd or unrealistic timeframe.

The second case is much more complex. While I have written in the past that "following the receipe" for any given methodology is usually best to gain experience and discipline while reducing dogma, there are certain elements of Agile - the daily standup meeting for the project team as an example - that can be used successfully on almost any project. The issue with mixing methodolgies wholesale is that it is usually very difficult to integrate them into a cohesive project plan because they approach major events and deliverables in completely different ways that are difficult to manage or introduce significant risks to the project. The brunt of this usually falls on the head of the project manager, and most in this situation find out that it's really difficult to be "Agile" and have incremental delivery if the organization political landscape insists that many meetings must be conducted, requirements "gathered" in minute detail, approved and signed-off at multiple levels, and revisited in full for even minor changes.

Is it possible to run "Water-Scrum-Fall" project successfully? Maybe, but so far I have not seen or heard about it from peers, in blogs and in the PM press. What I have heard about are a number of project failures - some spectacular - when PMs tried it; and other post-delivery failures when the organization finds out how many silos they just funded and built that don't and can't interoperate with each other because they were developed in Agile project silos with no coordination - organizational, technical, or project - between them.

If you're a project team member, understand what your PM is going through and how they plan and react to events. If you are a PM, what can you do - today - to improve your performance and relationships with your business sponsors and teams? What things - behaviors, approach, relationships need to change to make the project (and you) successful?

 

Where Enterprise Architecture and Project Management Intersect

My long-term readers know that I function as an enterprise architect and project manager (but not both simultaneously) and that I have taught (and continue to teach) project management courses at the university level for over 10 years.

Over the years, there has always been a measure of uncertainty and in more extreme cases, distrust of project management by EAs when applied to enterprise achitecture efforts. As I reveal later in this post, I find this situation to be unfounded in most cases, provided that certain conditions are met and adhered to by all parties involved.

Principle #1: Enterprise Architecure is a Function of The Business, Not a Project

Enterprise Architecture is currently undergoing a metamorphasis from a solution-oriented, IT-centric function to one that serves the entire business, including strategy and execution well beyond IT and IT solution delivery. While these changes will take a fair amount of time to fully realize, suffice it to say that EA will eventually morph into a department or division of organizations in their own right - organizationally independent of IT departments and divisions.

As such, certain functions of an independent EA organzation are not project-based, as certain other business and IT functions (accounting and network operations, for example) are not projects, but on-going operations.

Principle #2: Enterprise Architects Are NOT Members of IT Project Teams

 Two of the scariest proclamations about EAs and IT project teams that I've seen over the years are:

• Enterprise Architects should know how to write code (or have done so in a previous life)
• Enterprise Architects should be members of IT project teams

There are no studies, laws, regulations, or proclamations that decree that EAs should be (or have been) software developers in past jobs. Enterprise Architecture is not about writing or specifying software code or systems - it is about architecting optimized business processes and systems based on management's strategies for the organization. While software development certainly has its place in organizations, that is an IT function best left to IT and more IT-specific solution, data, and information architects (who are not, by the way, enterprise architects - even if the organization calls them such).

Since EA is evolving away from IT-centricity and IT project teams, it doesn't make much sense to make them members of IT project teams. However, it may make sense for IT project teams to utilize EAs as subject matter experts - who are advisors and give guidance to specific projects, but are not members of the specific teams OR responsible for any of their scope, timeline, or deliverables.

Principle #3: Enterprise Architects are Accountable for Scope, Deliverables, and Timelines for Major Bodies of Enterprise Architecture Work

Although Principle #1 above states that EA is a function within organizations - and optimally realized in practice as a department or other organized body in its own right with its own direct management, it is not immune from organizing major bodies of its work output as projects. Although the EA department or group may be persistent, its scope and subsequent work activities and output are not. Oftentimes, these activities and output are unique both in terms of the type of work performed and the results achieved - which fits the commonly accepted definition of projects - temporary endeavors to create a unique deliverable or outcome.

EA, like every other business function, must also prove its value to the organization, and not only at the end of the effort. Organizational sponsors of EA efforts must be reassured on a continuous basis that progress is being made and capital funding the effort is being spent prudently. Such assurances usually cannot be made on an ad hoc, verbal basis for very long. These various metrics are going to have to be proven on a consistent basis.

Finally, this principle applies to EA-specific efforts, not to those the EA group lends experise or assistance to with no formal, defined role in those efforts.

Principle #4: Certain Enterprise Architecture Activities are Project-based, and are Managed as Such

Some EA bloggers and twitterers show outright disdain for project management for various reasons. While that is unfortunate for whatever reasons they have, it does not relieve the organization or the EA function within it of its obligations in managing all standalone enterprise architecture projects in a prudent fashion. The old adage "you cannot control what you cannot (or don't) measure" applies to such EA efforts as it does to any of the organizations' other projects in every department or division. 

What this means, in general, is this:

• All EA efforts that have project characteristics (temporary effort of significant duration, unique product developed, substantial financial outlay and risk) are best managed as a project, with a project plan, timeline, budget, and...surprise...a project manager.
• The detail of project plans suporting these efforts, while largely situational, must be coherent and detailed enough that management funding the effort can get information on project progress, timeline, risk, budget, and performance easily. A judgement must be made on how much information about EA projects is relevant, when it must be updated and communicated, and what the risk scenarios are for the project. It is generally a mistake to either: follow an established project methodology (i.e. PMBOK) down to uneccessary and irrelevant detail; or call the project "Agile" with the intent of winging-it-as-we-go-along (which is what I have seen on a lot of projects proclaiming themselves to be 'Agile').
• Project managers involved in these works are managing the project and outcome/deliverables, not the EA team directly. If management intervention is necessary at some point, it is done by EA leadership, not the project managers (although the project managers may have input into such situations).
• A threshold must be established on EA projects where project management is required. Efforts that take a week to, say, a month are generally off the PM radar screen. Longer than that, or with substantial sums of capital being deployed make these issues more important and the ability to communicate status and issues to project sponsors and management is essential

I have remarked previously that enterprise architecture efforts and project management are often complimentary disciplines in many respects, not diametrically opposed to each other. If both groups appoach EA projects as a collaboration with agreement on scope, measurement, reporting, and other project nuances agreed to in advance and consistently applied/maintained, the sides should not only find the relationship satisfactory, but very benefical to both - as well as to the organizations they serve.

 

Agile Meets The Recession

It's no secret to anyone about the state of the economy, and the issues organizations face in keeping their businesses stable, including cutting costs. This also leads to the "do more with less" syndrome that project managers are facing on their projects - assuming that they aren't being canceled wholesale along with other initiatives.

Lately, I have been hearing flack from clients and in my Intro to Agile course that I teach at the University of Wisconsin-Milwaukee about two agile methods, pair programming and refactoring with respect to cost and time.

Pair programming is germane to Extreme Programming (XP), but can be used in almost any situation or methodology as desired. The gist of the technique is that while one developer sits at the computer and codes, another developer is looking over his shoulder catching errors and brainstorming with the first developer as the code is being written. They switch roles after a time, and members of the project team pair up with other members after a few days or a week (roughly).

While I am not personally a fan of the practice, I have seen it used fairly successfully in the past on specific projects. The argument against it now, which has come through loud and clear in the past few months is simply this: "We cannot afford to pay two programmers to do the work of one." That pretty much sums it up - the budget is cut to the bone, and the project cannot pay for additional staff to adopt or continue the practice. Not having (or refusing to spend) the cash to support this technique makes all technical arguments in its favor moot.

Refactoring code is being scrutinized heavily as well, particularly if it's "do-over" code that optimizes the system, but provides no new functionality or capabilities for the business or end-users. The argument here is "We cannot afford to refactor working code to optimize it unless it can be shown that there are distinct and immediate advantages/benefits to the business in doing so." Can't say I blame the business and product owners here as well if there is only enough budget to take one pass (or maybe two) at development in each iteration.

There are a number of methods to mitigate such risks, and if you're told the team cannot pair program and/or to keep technical (not feature-related) refactoring to a minimum, you have some choices to make regarding the project.

The primary method to mitigate these risks is to do some design up front. Not Big Design Up Front (BDUF), where artifacts use lots of paper and diagrams to describe a system and take many months to produce (as well as having dubious value to the programming teams). Rather, we do enough design to enable single programmers to write code that requires minimal refactoring or tweaking down the road for purely technical reasons. The thought here is that the time spent on design pays for itself in two ways: reduced staffing cost; and the reduction of technical debt to a point that significant amounts of refactoring are not necessary.

The business may complain that time spent in useful (that is, useful to the development team) design inhibits getting started on development, and we're agile, and we need to get a system up and running quickly. However, they cannot have it both ways - we either spend some time and money on intelligent, useful design, or we spend them on refactoring and higher developer head count during development iterations. I think that some up-front design is a better investment of scarce time and funding than doubling programmer headcount and/or rewriting code to 'optimize' the system without much benefit to the business users.

This line of thought also doesn't address changing requirements, timeframes, and other project uncertainties that are faced every day by development teams and their sponsors. That is a topic for another day, but suffice it to say that as good as Agile methods are in addressing uncertainty through iterative development and small, focused teams, we don't get those benefits for free, and never did.

Architects and Standup Meetings

Many organizations I consult to or are intimately familiar with have embraced certain concepts or 'features' of Agile development while eschewing others - in particular, the daily "standup" meeting where team members transmit and share information with leadership and each other. As I have remarked in the past, these meetings are highly useful when properly facilitated, but are not useful (and perhaps damaging) to projects when not run well with a controlled format.

Oftentimes, an IT architect is faced with supporting multiple iterative projects simultaneously - providing the overall architecture/technical direction to multiple teams working in concert, but very focused on their specific portion - their project - of the overall approach. Of course, leaders for each team have their separate daily standup meetings, and here is where trouble starts for architects in this type of role: they can spend almost their entire workday, every day, attending standup meetings.

I have been in the architect's role on large projects managed in this fashion utilizing multiple project leads/managers/scrum masters, etc. In each case, these folks wanted me to attend their daily standup, and while its great that they consider me part of their respective teams, I decline the invites because once these teams grow past a quantity of say, three, a substantial part of my work day will be consumed in standups - that leave little room to get "real work" done or attend to other important issues.

This also takes into account the fact that a lot of standups go well past the allotted 15-30 minutes for various reasons, are held in numerous locations including different worksites, and generally deal with granularity and minutae that the specific teams are dealing with - code, testing, etc., that don't always need architectural input and direction.

Architects still need successful interactions with these teams on a regular basis - so what to do about it? When talking with project leads and facilitators in such situations, I offer the following:

1. I usually attend specific project standup meetings once per week, and generally speaking, Wednesday through Friday is better so the team has some work completed or in process as the week progresses. Mondays are not real effective because everybody is usually settling in from the weekend.

2. If there are architecture-related impediments or issues that need quick resolution, I'm always available to meet with teams or individual project leads and members as such needs dictate. This is not a standup meeting, but one to resolve issues or impediments, and are focused on those topics alone.

3. When there are architectural work products or issues to discuss, a separate meeting for such topics is required with the necessary attendees invited. From my experience, these types of meetings do not work well in a 'standup' format.

What I am not advocating here is that architects assume an "ivory tower" approach to these issues - becoming pompous that they somehow "grace" a meeting with their attendance and inputs. The fact of the matter is that in the scenario I'm describing, architects' time and efforts must be used prudently, and spending 1/2 to 3/4 (or more) of every day in various project standups is not going to be very productive for the architect spending such time, and the teams trying to gauge where they are on projects and resolve issues as quickly as possible.

Support your iterative/Agile project teams, but know your specific role and apply your time and effort wisely.

14th Carnival of Enterprise Architecture Coming January 15, 2009

The 14th Carnival of Enterprise Architecture that I host through Blog Carnival is coming up on January 15, 2009, with submissions due by January 14, 2009. If you have an EA- or IT-related post that you'd like featured through the Carnival, you can submit the Permalink URL and related information here.

This is a very easy and effective way for EA and IT bloggers to get their messages across to a wider audience, and I hope that EA and IT bloggers will consider submitting their best pieces to the Carnival. Please note that you do not have to be the author of the material to submit it, as long as it: a) meets the guidelines below; and b) honors the author's copyright and fair use guidelines.

As always, here are a few pointers for article submissions to the carnival:

* Off-topic material, sales pitches (direct or disguised) for products & services, and content spam will be not be published. Prior to every carnival episode, I delete a number of pieces of obvious spam, vendor ads, and off-topic material prior to publication - and it's a complete pain in the rear, believe me. Please don't waste your time or mine and thanks in advance.

* Feel free to nominate blog posts of others for the Carnival, but make sure to identify the author!

* Material posted in previous editions of the Carnival will not be re-published, regardless of who submitted it and when it was originally submitted.

Again, the deadline for submissions is January 14, 2009, and the carnival will be published on January 15, 2009. I look forward to all worthy contributions!

The 14th Carnival of Enterprise Architecture that I host through Blog Carnival is coming up on January 15, 2009, with submissions due by January 14, 2009. If you have an EA- or IT-related post that you'd like featured through the Carnival, you can submit the Permalink URL and related information here.

This is a very easy and effective way for EA and IT bloggers to get their messages across to a wider audience, and I hope that EA and IT bloggers will consider submitting their best pieces to the Carnival. Please note that you do not have to be the author of the material to submit it, as long as it: a) meets the guidelines below; and b) honors the author's copyright and fair use guidelines.

As always, here are a few pointers for article submissions to the carnival:

* Off-topic material, sales pitches (direct or disguised) for products & services, and content spam will be not be published. Prior to every carnival episode, I delete a number of pieces of obvious spam, vendor ads, and off-topic material prior to publication - and it's a complete pain in the rear, believe me. Please don't waste your time or mine and thanks in advance.

* Feel free to nominate blog posts of others for the Carnival, but make sure to identify the author!

* Material posted in previous editions of the Carnival will not be re-published, regardless of who submitted it and when it was originally submitted.

Again, the deadline for submissions is January 14, 2009, and the carnival will be published on January 15, 2009. I look forward to all worthy contributions!

One Reason We're In A Recession...

Looks like these idiots thought that my "Measuring Technical Debt" post yesterday merited attention due to the "great money management tips" I offered....

There are myriad ways people lose money in the financial markets, and this is obviously one web-related way to do so.

Disclaimer: I am NOT an investment advisor. Not federally insured either. Some investors can and do lose money. Your mileage may vary. Specific investment performance is not guaranteed. LOL

Measuring Technical Debt

A number of bloggers including yours truly have been revisiting the concept of technical debt over the past month or two, given the parallels between it and the financial kind making headlines every 10 minutes; and also the fact that projects are being reined-in across numerous organizations due to budget, economic, and headcount issues caused by difficult current economic conditions.

Martin Fowler recently posted an interesting piece about how one would go about measuring technical debt, and I'll add a few other items to consider.

One thing about technical debt that often gets overlooked is that it cannot be reasonably measured or estimated until it has been incurred - that is, after the fact. Financial debt scenarios are estimated in a more straightforward way because certain critical factors such as interest rates and payback periods are known up front, reducing the uncertainty, but not eliminating it.

Martin also mentions that measurements of technical debt are subjective because the resulting system is measured against a system in, as he put it, "an imaginary state." While this is true in a substantial number of cases, I believe that some (not all) of the subjectivity in such measurements can be mitigated if an overall design/architecture exists up front. How much design and architecture? That's also quite subjective, but such artifacts would establish a baseline that facilitate objectivity in measuring and controlling technical debt.

Then we come to the debt measurements themselves. The most straightforward metric with technical debt is time - how much time will/did it take to build/refactor assuming that the overall system was "clean?" Those estimates come in units of time as that what the project team utilizes daily and reports in standups or project meetings. However, time as a form of 'debt' usually doesn't resonate with non-technical managers - but money does. For example, I can tell a project sponsor or product owner something along the lines of Martin's example - 'if the system was 'clean,' we incurred 2 days of interest on our technical debt." While that usually gets acknowledged, the ramifications aren't clear.

What does get their attention is when that 2 days of interest is converted into monetary terms. The straightforward way of doing that is: (Cost of involved team members per day) X (Number of days of interest). For this to work, we must know how much 1 day of labor per team member (hours work also) is costing the project and multiply it by the number of team members involved. Then multiply it by the days (or hours) of interest paid. Now, we have an approximation of how much the technical debt cost in financial terms, which will definitely get management attention if its high enough (and hopefully not high enough to get the messenger shot).

Again, keep in mind that these measurements are made after the technical debt is incurred, and are rough approximations, not cold hard facts. Having a design/architecture as a baseline improves these measurements, otherwise the 'imaginary state" (or design/architecture after the fact) as Martin describes must suffice.

If anyone has better methods or optimizations on this, I'm all ears and eyes.