Search This Blog

29 September 2010

Good news for SMB Projects

I don't know about you, but it feels like forever since we've had much good economic news. Even though this recession is finally, officially over, the number of lost jobs is just staggering. I don't have to tell you that it will take a long time to dig the world out of this deep of an economic hole.

But all is not lost! As politicians in the US are always quick to point out, it seems that small and medium businesses are fueling what growth there is in the economy. It seem as if technology spending in these sectors is coming along nicely as well. Overall spending is up, software spending is up and hardware spending is slightly down. Not too shabby.

As I read through the report, a few things strike me which could impact project team members. First, while spending is up 4% this year, we're still trying to dig ourselves out of the hole that we've been in for over 10 years now. True, the tech bubble of the late 90s is still to blame for a lot of the stagnation, but I am unsure when the next big bump will come in tech spending. The majority of hardware spend is on replacing existing systems, not expanding or adding new systems.

Tech can often advance productivity, if implemented wisely and correctly, but there isn't anything big I can see on the horizon. The cloud has been with us for a couple of years now, but SMB spending on it is decreasing, not increasing, which indicates that it might be a fad which is finally petering out. 

Second, there is money to be made in not spending money. Not the best sentence in the world, but it seems to be the path we're on. With spending relatively flat but virtualization on the increase, this is a sign that the market is moving towards yet again doing more with less. 

I do find it very interesting that one area of growth is in hosted company email. This mirrors the growth seen in Google Apps for Domains. If you're a project person who specializes in enterprise messaging systems, this is a trend you need to be on board with as it will likely impact you soon (if it hasn't already). This fits with the overall theme of more with less and with a lack of hardware expenditure.

In the end, the study's authors come to the same conclusion that I came to... hold the course, weather the storm and live to do your massive projects once the economy turns around. What about you? Is your SMB company spending for new or just trying to get by with what you've got?

28 September 2010

Self directed teams

One of the teams I ‘manage’ has been fairly consistent (i.e. mostly the same people) over the last 3 years and we are now in our third project together. They are a lovely bunch of people and a well integrated team. It was tough getting to this state, but it appears to be worth it.

Here’s the thing; on this last project I have given them a one line goal, a deadline and a list of stakeholders. I barely talk to them except to get a weekly progress update.

They are on track and making decisions about what should be in and out of scope, and where quality can be flexed to accommodate more or less features. About once a month they are coming to me to ask for assistance in clearing an external impediment.

I love managing them because it’s almost completely automatic. I get to focus my attention on the other teams I am working with which need more guidance and support.

This is an example of a real self directed team working on real enterprise software projects.

27 September 2010

The A-Team

Some things in life are just happy accidents. Sure, many of them include an element of hard work and determination, but having good things just fall into your lap doesn't necessarily hurt, either. My first job out of college, technical support for a large printer manufacturer, led directly into my first job as a business analyst. I did a lot of hard work as a tech support agent, which led to the opportunity as a BA. The happy accident was the project to which I was assigned; the one that contained the best of the experienced analysts in the division. They were the 'A-Team' and I was able to sit and learn their techniques while I applied my experience as a business area representative. Had I not been assigned to that team, I never would have gained the solid foundation upon which my career currently rests.

Because of that experience, its always been a fascination of mine how it is that such a team of all-stars is assembled, and thus why this article in was so intriguing to me. It details the different cast of characters needed to make a special-ops team successful. Its no surprise to anyone who knows me that personnel #7 fits me like a glove. One of the things I'm known for is simply knowing a little bit about everything regarding the current state and future trends of technology. If you want to know what's hot, you come to me. Chances are, I know about it and can tell you how it might impact business.

Selecting A Team

While the article did a good job of explaining the personalities needed for a successful team, it didn't really go into the mechanics of how to go about assembling such a team. Being a member of first-line management, this isn't something I've ever been able to go and do. My team, and a great team they are; one I wouldn't trade away, came preassembled, but someone definitely spent some time developing and selecting quality people. One day I do hope to be given the opportunity to assemble an A-Team, and here is how I intend to go about it.

First, as with most things, the need for such a team must be recognized and sanctioned by the stakeholders. The problem will need to be something that no existing team can manage on their own or the problem domain is one which is unfamiliar to any existing team. Just as the article states, having 'air support' in upper management is critical.

Second, the need or opportunity must be of great importance. You don't assemble a team of all-stars to figure out a better way to clean the company bathrooms. Forming such a team as this by drawing the best from each of the business units create a brain-drain in the impacted teams. That's not necessarily a bad thing, as other team members will be forced to either pick up the slack or let the department fail; both outcomes are learning events which can help to grow team members. This is still a risk and one that should not be undertaken lightly.

Alternatively, you can hire new team members for your A-Team to avoid a brain-drain. Beyond the additional headcount which your business will need to absorb, you'll also have existing team members question why they were not promoted to the new team and why these new team members are better than ones who have been there for a long time and know the company and existing business. Once again, this is not necessarily a bad situation, but one that must be considered when putting together the team.

Driving This Bus

Once you have all the right team members, you need to match up the tasks in front of you with the skills, knowledge and passions of the team members. As the book Good to Great said so well, you need to know which people are in which seats on the bus. Placing someone who doesn't have the skill, knowledge or desire for certain tasks in a role where those same tasks are the primary function will not necessarily lead to disaster, but it will frustrate your resource and likely yourself.

Even with an A-team, its unlikely you're going to have an expert in each of the areas you need covered, so at least someone will end up doing tasks with which they are not comfortable or would rather not do. This is a part of life in projects.

The biggest hurdle in keeping the bus headed in the right direction seems to me to be communication. That first project of mine, we had relatively few limits on resources, both people and budgetary, yet so many of the problems we encountered led back to missing hand-offs between the different functional divides. Even A-Team employees can get caught up in their own area and forget to collaborate when they reach a touchpoint with another team member.

One solution, the one which the team I worked for requested, was more general status update meetings in order to improve communication. This is one way in which we were not an A-Team. Status update meetings are fine for high-level overviews, but do little to facilitate the low-level collaboration that must occur if you're planning on creating a useful, cross-discipline solution. Our failure on that project was in not spending enough time with each other in discussion about how the different areas would collaborate once the solution was in place. I lost track of the number of times that we built bridges to nowhere because the other analysts did not realize they had to catch a process hand-off.

Your A-Team

So who would be in your A-Team? How would you run it?

24 September 2010

Maslow and Money

About six months prior to my promotion from tech support agent to business analyst, I remember looking around myself at all the other very smart techs in my department, all who had CS or business degrees, and thinking to myself, I don't stand a chance. It wasn't that I was actually less intelligent or educated than everyone else there (I like to think I'm a smart guy who worked with a lot of smart people), but when you've got that much quality surrounding you, its often difficult to be noticed amongst all the others. This realization led me to return to school during the evenings and weekends in search of an MBA; something that almost no one else around me at that time had.

That decision to further my education was, next to marrying my wife, the best one I have thus far made in my adult life. Six months later, I was out of tech support, a newly minted junior analyst and on my way to a career without a headset. The downside was, despite having a vastly different job role than the one that had defined my life for the prior three years, I was still being paid like a tech support agent. I didn't get a bump to analyst pay bands until nearly 11 months later.

As knowledge work goes, analysts, developers and project managers are generally paid fairly well, at least compared with your average ditch digger. Even as much as I at times despise my cubicle, I'd much rather spend 8 (ok, 10) hours in it every day than 8 hours digging a hole in the ground.

Last year, I once again decided to increase my knowledge (and the number of acronyms included after my last name) and studied for the CBAP. As I slogged through the material, I found it odd that items such as Maslow's Hierarchy of Needs were listed as secondary reference material for the exam. While I understand at a cognitive level how this impacts stakeholder relations, it seemed an odd inclusion when the topic is business analysis. Sure enough, there was a question on the exam about the hierarchy so I was glad to have spent an hour or two reviewing material I hadn't thought about since college.

Despite my concerns about Maslow's inclusion in the study material, when I run across articles such as this one regarding pay and happiness, I realize that my initial inclination to discount the material's inclusion was incorrect. You don't have to look far online to find that when it comes to non-management jobs, business analysts are paid fairly well. Developers and project managers are doing equally as well themselves. True, it is usually only the most senior analysts who reach the 'magic' $75k/year that leads to 'happiness', but if you're around long enough, you'll likely get there.

I think back to Maslow's hierarchy and mesh it up with the article about pay and happiness and realize that there is some truth to it. As my career has progressed and I've inched towards that 'magic threshold', my life has generally become happier. I didn't go out and buy a new car or a newer house with my increasing wealth (although I have consistently increased my savings for retirement), but its the realization that I am paid enough to not worry about bills month to month that has relieved a great deal of stress and anxiety from my life. When I was laid off four years ago, I had enough of a nest egg stashed away that I could have easily been unemployed for six months without going into debt, so I spent the time finding the right job, not worrying about just getting a job.

This 'threshold' has a lot to say about project team dynamics and relationships with business areas as well. During my career, I've run into more than a few project team members who were dissatisfied with their pay, but usually only in relation to other team members who they felt were paid in great excess of their value to the team. The business areas I've represented, especially in the service industries, often see project team members as intruders who don't really know what's really happening and can only repeat what the subject matter experts tell them to say. They don't see the value we provide, only the larger salary we often command.

What about you? I won't ask if the $75k threshold has made you happy (or at the least minimized your unhappiness) as that would out your salary to the world, but do you agree that such a limit exists?

22 September 2010

Ethical Analysis

The last few month's I've been considering what area of business analysis is overlooked and, if I put a little effort into it, where I could possibly add a significant portion of information in the form of a publishable book. One area that keeps coming up in my mind is ethics for those in the business analysis role. The IIBA has an official code of conduct for CBAP recipients but no official code of conduct for business analysts. Doing a quick Google search for Business Analyst Ethics returns nothing more than job queries and a link to a single certification for analysts. If this is any indication of the state of study regarding this topic, the field is wide open.

My interest in the subject was peaked even further last week when it came out that a Google engineer was fired for having used his privileged access to inappropriately spy on minors and other customers. Almost every company that has hired me as an analyst has given me access to a significant portion of their sensitive data (and I have always respected that trust, never having breached that trust). But it is obvious that breaches are possible and it is an issue that every company and every project team member should consider.

It is ironic that, when I decided to write this post earlier today, only an hour later, today's OneFTE comic came out:

Target Markets

Sadly, this isn't far from what could be when ethics are divorced from access. I see that there are several avenues that an analysis of ethics in analysis could take.

First, I could see a discussion about the source of our ethical standards and how they can be a reflection of our societal values. Some cultures may have differing views regarding data security and what is considered theft, so a review of these differences may be appropriate as well.

From there, the topic could branch out into how ethical standards could apply in the areas common to most analyst roles. Items such as stakeholder interaction, data integrity, system integrity and process integrity could be included.

Lastly, I think the discussion needs to look forward towards the future as our job as analysts will be changing in the not too distant future. As technological processes continue to mature, how will analysts continue to provide value to the organization? What about the impact of massive data centers on our environment and will analysts help drive down the energy utilization by keeping our stakeholder's expectations in check?

The biggest roadblock to me compiling this information, besides a day job, this blog and a family, is the question of would anyone actually take the time to read all this? Yes, a hungry audience is not the reason I would pick to write on the subject, but its always nice to know someone might actually read the work once it is complete! (Kind of like we all wish for our stakeholders to actually read our requirements documents!)

So what do you, the readership of think?

20 September 2010

2010 IIBA and Forrester Research Analyst Survey

Forrester Research and the IIBA have teamed up again this year to study the role, processes, and tools of today's business analysts. The two organizations are looking for anyone who currently performs business analysis functions, regardless of title, to share their thoughts and experiences on the current state of business analysis.

I took the survey and it took me less than 5 minutes to complete. The deadline is October 8, 2010, so make sure to take it soon. You can find the survey here. If you participate in the survey, you will receive a complimentary report on the results once they are compiled.

Given my criticism of surveys in the past, you might find it odd that I'm actually in favor of this one. I'm actually more in favor of this as it surveys about people, not necessarily trying to find answers to why things happen. The more people that participate in a survey like this, the better chance we have of finding out a real answer, so go hit up the link! I can't wait to see the results.

17 September 2010

My New Hero

Forget Batman or Superman, Carl Malamund is my new hero. This guy gets it.

Time is in short supply for all of us, so if you skip forward to around the 5 minute mark, listen to him discuss the ERA program and its challenges. If there is any poster child for a project that needed to be put out of its misery long ago, this would be it. A failure to really understand the goals of a project will doom that project. This is a requirements failure in its most painful form, one that takes money directly out of my pocket and fritters it away.

16 September 2010

Ted tells me he's working hard!

I'm off to Fiji.  Have a good week.

What I think is important

I took other peoples comments about me (via Linked In references) and threw it into Wordle to see what I am about.  A loose but effective check on what I really value as opposed to what I say.

Wordle: References

Challenge your assumptions on the cost of quality

The usual thinking is that the earlier your find a bug the cheaper it is to resolve, and that the cost of defect remediation increases exponentially over the product life cycle.

Don't buy that at face value.  

Architecture, the team's capability and the tools and systems the team use will all affect this model.  It's not infeasible that the cost of remediating a bug in production is less than avoiding it in requirements discovery.

In fact, why don't you start measuring this today?  how much time is spent on each aspect of the product delivery process, and what does each cost in terms of rework?

15 September 2010

Are We Encouraging Stupidity In Our Users?

Lets face it, if you read this blog its very likely that at least some part of your job involves software development and/or implementation projects. While the work project professionals do extends above and beyond applications, we spend a large amount of our time working on or around a development effort of some kind. We generally like to think that our projects add value (or at least they should add value) to our organizations and make the lives of our users better. Most often we feel strongly, maybe even passionately, about the work we do being for the good of our stakeholders.

It is these same feelings which make news articles like this one seem so crazy. People complain of sensationalism in media and I think this is an example of just such behavior. When your title is 'How good software makes us stupid', I can't help but wonder if the author is pushing for a particular outcome or if they're just trying to drum up a few extra hits to the website.

The more I think about the article, the more bunk I find it to be. The reason is simple... good software enables its users to spend more time doing things that are more important, not in the endless regurgitation of facts. Lets use the London cabbies cited in the article as a good example.

Yes, its true that GPS would keep the cabbies from needing to know every nook and cranny of London's streets. Isn't that a good thing? You don't need to spend years doing rote memorization of streets; you can hop in the cab, turn on the GPS and immediately begin to add value. This then means that members of the labor pool who are looking at a cab driver job as a step up in the career can more quickly get into the market than they could previously.

This also means that cabbies who are looking to move up another step in their career have the ability to do so without spending as much time doing memorization for some other job. If the information you need is always no more than a google search away, you free yourself up for a lot more time innovating yourself on to something bigger and better.

When pointing out this article to my wife, who is studying for her PhD in clinical psychology, she had an interesting point I feel I must make. There is a phenomenon called the Flynn Effect, which shows that all countries have been increasing their IQ by three points per decade over the last 100 years. That's all countries mind you, not just industrialized ones. It has been during this same time period that technology has dramatically changed our lives (hopefully for the better).

Lets put this in perspective. Average IQ has increased 30 points in the last 100 years. The standard deviation for IQ is 15 points, so in the last 100 years, average IQ has moved two standard deviations up the scale. Quite impressive, but I'm not done yet. Mental retardation can't be defined by IQ alone, but having an IQ that is two standard deviations below the normal (meaning 70) is generally considered within the correct range for that diagnosis. Gifted programs usually start at an IQ of 120. So, this said, the average IQ of today would have qualified as genius level 100 years ago. Average IQ of 100 years ago would be listed as a potential diagnosis for mental retardation today.

Now, there are LOTS of theories on why this is (go read the article for them) and by no means am I advocating that technology is driving an increase in 30 IQ points in the last 100 years. What I am saying is that more technology is assuredly NOT correlated with a drop in IQ and is not causing our IQ to drop.

That said, if you've seen the article I quoted at the beginning being passed around the office, don't fall prey to bad reporting. Always look deeper, without just reading it at face value. As project team members who likely advocate technology as at least a portion of most solutions, this is what we're trained to do anyway, so this is just another chance for us to polish our skills. Technology is a good thing and don't let anyone tell you differently.

13 September 2010

Upping the Revision Number

A few days ago, a few more than I intended due to the sudden onset of an illness I am just now getting over, I asked the followers of this blog about how they went about increasing the revision number on a document. Am I ever glad I did that without just ripping off a post from the hip. Not unexpectedly, you all had some awesome answers that I'd like to point out and then toss in a few thoughts of my own.

But before we begin...

Before I do that, I have to ask one question though... do we put too much thought into this question? Does it even really matter? When put into the greater picture of projects, programs and products, I really don't see that it does matter. Who really thinks about the revision number of something when they set out to do a task? We generally think of things in two ways: how we do it now and how we did it previously. Sometimes that 'previously' can have multiple iterations if we've spent enough time in the same role. You could argue that there is a third way, how I want to do things, but that is something that usually comes before a revision number increment of a document and thus doesn't exactly fit our overarching question.

If it doesn't really matter, then why do we fight over it so much? I've seen knock-down, drag-out fights over this seemingly insignificant issue. Often this is a ruse for people who want to bicker about bigger issues but can't find any other way to win their arguments. Others see this issue as a question of correct, at least in their mind, methodology and not updating correctly is a failure to adhere to the rules. Whatever the reason, I've seen many a good project team member go down roasted in flames over something that can be as simple as on which side of a decimal a number should increase. What is most important here is to provide a recognizable way to indicate to the readers of a document that something has changed and that it is in their best interest to seek out those changes.

I am glad to see that not a single person said they had no structure or that their versions depended upon printed copies. Thankfully we've come far enough to realize we need structure and that printed versions are an inefficient method to maintain version control. (Ok, at least most of us have probably come to this conclusion!)

Keeping it simple (kind of)

Nearly everyone suggested that an automated versioning system, usually in conjunction with a check-in / check-out system, provides the best way to manage the process of versioning. Only one person can be editing a document at a time and until they are done, the document is locked as is. Once the check-in occurs, the version increments automatically. There is no methodology dispute here and no haggling over the format of the number; its simply a function of the system.

I'll use this point to ask the group another question... how will concurrent editing such as is built in to Google Docs and newer versions of MS Word change this paradigm? Allowing multiple people to collaborate on a single document in real time, each making changes, means automated versioning is really not possible. I personally see this collaborative authoring to be a good thing, but it will introduce complexities we hadn't yet thought of.

Back to the point, I put 'sort of' in my header and you're probably asking why? Frankly, as nice as document control systems are, even large Fortune 500 companies, maybe especially these companies, have been somewhat slow to embrace this technology. I've worked with products from a few different vendors and while they're nice, they're usually expensive and the check-ins can be gruesome if no one first put a lot of thought into exactly how they should fit into everyone's workflow.

The second problem comes when only the project team members have access to the tool and the stakeholders do not. At this point controls become moot. Within a project team it is often easier to enforce a disciplined approach to document management, but stakeholders, who may not see as much obvious merit in the approach, can make all the changes they want, which then makes the project team's job that much more difficult when it comes to reconciling multiple marked-up copies of the same document.

Another Paths

If a version control system isn't available, then general consensus was using a major/minor (X.Y) versioning system. Most took the path that the project team revisions took place in the minor number and reserved the major number for some sort of wider review.

Craig Brown suggested that the major number is often used as a way to denote review by a steering committee, if one is part of the review process. Cleggton uses the minor number for any time the document is reviewed and that the major number is a milestone , gate-review or baseline review where the document has reached a level of sign-off or buy-in from stakeholders.

iqi616 mentioned that they ask the reviewer to append their initials to any reviewed copy they are submitting. This is a practice I personally adhere to when reviewing a document for anyone else. I know how difficult it can be to manage having 20 people review a document and trying to keep it straight as to who said what.

Karyn C brought up a point about using the major number in the scheme to denote a document reference Id. The minor number then becomes the only revision number so that you always know you're looking at revision Y of document X. While I've seen (and used) a document identifier as part of the document name, in combination with a more human friendly descriptive name, I don't think I've seen it used in quite this way. Karyn C, I'd love to know the origin of this method if you could share it with us in the comments.

A Pet Peeve

Craig Brown, co-owner of this site, commented that  documents marked as 'Final' rarely are and should probably not use the file name in this way. I've not seen anyone do that around me in recent years, but it was common place when I started out as an analyst. My experience agrees with Craig, its just a silly practice.

I usually go a step further and say that putting the version number in the filename is nearly as silly. If you're going to add anything in the document filename beyond the document's actual name (and possibly a project/company reference number), I suggest ending documents with the date of the revision in the 'YYYYMMDD' format. I say this because that way you don't usually need to guess which is the newest as the different versions of the document automatically sort themselves in a file manager.

The last thing that was brought up by several people was track changes and/or read-only copies. Why list this as a 'pet peeve' if so many people seemed to be passionate about it? I personally am in favor of the idea and find it incredibly useful, but have mostly given up on using it as my stakeholders seem to generally hate the function with an unrelenting passion. Maybe it is just the ones I've worked with over the years, but they either refuse to learn how to use it and thus don't review the document, or I receive printed copies with changes penciled in because they won't edit electronically unless they can make their changes inline and then highlight. It honestly became too much of a hassle for this analyst, so I adapted and moved on rather than spend even more time fighting against what was a losing battle.

Wrapping It Up

Thanks to everyone who made comments. I definitely want to do this in the future with more topics. If you think of one you believe would be fun to do, drop me a note in the comments.

8 September 2010

Simplicity, Complexity, Complicated and Complexification

For a while now I have been unable to comment on Jurgen Appelo’s blog. (Is it Chrome? Is it a setting on my desktop?) So I’ll comment here.

He’s posted a great article today that I think really helps clarify a problem we have with communication. Some domains are simple while some are complex. And the way we talk about them can be either simple or complicated.

Jurgen has framed these two aspects of simplicity into a new model (for me at least.)

I think it's instantly useful in helping teams understand that they need to work on making their modelling of systems simpler to enable communication and shared understanding, even though some domains are inherently complex. You can’t make a trip to the moon simple, but you can make the conversations easier.

Jurgen, this is an outstanding post. Thanks for sharing it.

(This may also dovetail into a recent Stephen Jon Whitty paper/talk about how project domains really are different and maybe we need different approaches for each of them.

Question: When do you up the revision number on a document?

I've been kicking around a few ideas in my head recently as I put together a post on document revision numbering. As my thoughts have percolated over the last week or so, I realized that I'd like to put the call out for thoughts to the readers of this blog prior to posting my own thoughts.

So here's your chance... what do you, readers of, think about document revision numbering? Do you do it? When do you increment it? Do you use major/minor numbering? Do you have any specific methodology is it really whenever you feel like it? What is your starting number?

Post your thoughts in the comments and I'll include them, with proper attribution, in my post!

7 September 2010

Projects are about people, now deal with that

I have to endorse Bas de Baar's latest post.  Bas is right into the sociology of projects and his latest post is another great reminder abut the human aspects of projects.

Your relationships are more important than technical skills to both you and the projects you work on.   Sure, technical skills are both important and useful, but not nearly as important as your relationships with your team mates, customers and partners.

3 September 2010

pernicious relativism and logical positivism

We say that Project Management is about getting things done, which means that at the end of the day pragmatism beats all methodologies and theoretical models.

Just what is pragmatism? And why does this approach to work bring so many of us into conflict in the workplace?

It's been called 'pernicious relativism' by some and logical positivism by others. It seems to me that pragmatists are about getting on with things, but we operate in a world of people who seek 'one best way' to get things done. Maybe there is one, maybe there isn"t.

Maybe the important thing to do is try something and improve on it.  And here we see the link between pragmatists and empiricists.  As we start to deal with empriricism we start to migrate back to the idea of a theoretical "one best way"

Once again I find myself in need of the consultant's quadrants.... Pragmatism and philosophizing.  Theory and pragmatism aren't opposites, they're orthogonal. And just where is the sweet spot between theory and pragmatism?

2 September 2010

Managing expectations

Success, at least the ephemeral success of a happy customer, is achieved through exceeding expectations. Set low expectations and it’s easy to succeed. Set high expectations, and even though you do an awesome job, nobody is really that impressed.

You aren’t really in control of a person’s expectations. Despite all the effort you put into setting realistic expectations about your team’s capability, or the difficulties of the problem you are tackling, people will still be influenced by other extraneous factors.

They’ve seen all their corporate projects run over budget and delivery disappointing results constantly. They’ve seen Facebook become an internet behemoth in less time that it took for their billing transformation project to get to it’s first release. Or they’ve simply gotten used to using Microsoft Powerpoint 2010 and expect all new systems to have similarly advanced features.

People’s expectations don’t match reality. No matter how hard you try to convince them.

What can you do? Function Points? Story Points? Planning Poker? Incremental releases? Rolling waves? Abandoning estimates altogether?

What’s your plan?

1 September 2010

COTS Selection RESOLVED (You Make The Call)

In an earlier post we presented you with a situation about a COTS (Commercial Off The Shelf) software package selection process. Here are some things that could have made this process better.

Square One

The first suggestion on improving the selection of a COTS product is the same as any internally developed application, namely a better understanding of the goals of the project. While your stakeholders feel that they could see labor and customer satisfaction increases with a new system, it wasn't clear (intentionally) from the description that the stakeholders wanted a COTS package, only that the CIO preferred one. Was there a bias on the part of the CIO towards using a COTS package or did she think it just made more financial sense to go that direction? Asking additional questions during the initial discussion with the CIO would have been a good first step.

Next, why was a list of current system functionality given to the vendors? The CIO made no mention of wanting to try and replicate the existing system in a COTS package. If the users main complaint is speed and older technology, could the existing system have been enhanced to meet those needs quickly? The stakeholders did not say they were unhappy with the system as a whole, just those two aspects of it.

But a more fundamental question is what do the stakeholders need? If the existing functionality works for them, with the requested speed improvements, then it doesn't sound as if they were necessarily unhappy with what the current system. If speed and old technology were ways users were expressing their displeasure with a product that was in reality more deeply flawed, only a rigorous review of the business processes in comparison with the system processes will find the underlying problem.

At its core, not enough questions were asked. The price tag returned by the COTS vendors were set very high as recreating an unknown system on top of their product is not usually cheap. Such a high price tag is a method vendors use, and rightly so, to provide incentive for clients to reassess their request and frame the conversation in terms of actual needs and not just a functionality list.

What other thoughts do you have on this situation? Have you been in a similar place yourself? Let us know what you did in the comments.