Search This Blog

31 August 2010

Project Phoenix, Something I Must Share

The first project with which I was ever involved which actually made it into production, was entitled Project Phoenix. This was at least the third try at filling this niche within my then employer, and there were probably many more aborted attempts prior to that 'success'. I use quotes because its hard to call something that was 9 months late and slow as molasses as true success.

That project also had what was probably the most contentious vendor relationship, with the implementer not the software vendor, that I have ever seen. There were days that I, as a tester, refused to even enter the test lab as the environment was so toxic and cancerous. I still cringe to think about some of the acts in which I participated. We had a plant in the corner of the room that must have been fed a constant diet of Miracle Grow as it lengthened nearly before your eyes. The team joke was that we tossed it a consultant every other day in order to keep up such a pace. Definitely not the way to start out your life in projects.

All that said, today's comic from 1.00 FTE brought much joy to my heart. If you've ever been involved in a Project Phoenix, then this one is definitely for you. Let us know more about your Project Phoenix in the comments.

Do you remember your first?

30 August 2010

Erasing your Project Identity

Eric Schmidt, CEO of Google, recently commented that at some point in the future, people may need a 'reset button' on their identity. The basic idea he had was that when we are young, we engage in activities that we may not want to be associated with as we mature and start being members of mainstream society. As more and more recruiters start to google each and every applicant, our past, as recorded by Google and other search engines, becomes more and more of a hindrance to our futures.

I find this concept novel, but think that as naive as we are as high school and college students, eventually the pervasiveness of technology in our world will make it so that this lesson is learned soon after we are taught that the stove is hot and the backyard pool is dangerous. It won't be something we generally worry about because we'll learn what to post and when to post it, just like we'll learn reading, writing and arithmetic.

But if that's true of our personal lives, what about our project identities? Once, and likely still today, each of us has a file in our manager's desk drawer that contains all of the past reviews, time off requests and possibly even official sanctions and reprimands. As all of this information recorded on dead trees transforms into  data on a server in the cloud, what safeguards are in place to keep it confidential in today's world where top secret government documents can be removed on a CD labeled 'Lady Gaga'?

Personnel records are not the only items kept electronically; our project documents are almost always kept that way as well. Sure, you likely have a stack of signed capital request forms (CRFs), project charters or requirements documents moldering in a corner drawer or cabinet somewhere, but every revision of that document is likely also contained on a server or possibly your PCs local hard drive as well. What happens when that first requirements document you wrote, you know that one with a 5% misspelling rate because you forgot to spell check it, with grammatical errors in every other sentence and with completely non-standard project language used, is put into the hands of your new CIO as an example of your 'regular work'. Is there a way to have your project history reset?

Reset #1, Don't Make Mistakes

Probably the most unreasonable and unlikely option, I mention it first to remove it from discussion. Sure, we've all met that one project person who seems to have the Midas Touch and never is caught making a mistake, but its rare and unlikely to last for more than a short time.

Reset #2, Different Scenery

The first way to reset your project identity is to simply switch employers. Having worked for several different large corporations in the last few years, those original requirements documents I wrote as a junior BA are (thankfully) buried on some shared drive at my first employer. Sure, I have a copy of them on a CD in a desk drawer, but they don't live anywhere they can be accessed by anyone but me.

As I've progressed in my career, I've still had a few less than optimal requirements documents. Different reasons, such as lack of time to thoroughly vet the requirements or lack of review on the part of my stakeholders, is to blame for these unsightly blemishes, but they are part of my permanent record with each of my employers and the documents have me listed as the author, not my stakeholders.

Reset #3, Bury It

Given that we're all going to make mistakes and that we can only realistically move away from so many jobs before we earn a reputation as a short-term employee that isn't interested in sticking around, we can start to come up with ways to hide our mistakes.

The best way to bury your bad output is by producing a lot of quality work now and in the future. Producing excellent quality work will go a long way in removing any stigma associated to your past failures.

Moving Forward

Some of the methods I've mentioned will be effective in the short term while others will produce success for the remainder of your career. What are some other ways you can think of to reset your career mistakes (besides large electromagnets in the data center)?

27 August 2010

COTS Selection (You Make The Call)

Its time for yet another installment of our favorite game here at, You Make The Call! The rules are simple... we'll present a situation that is based on a real life project with which we have been involved. If you think you have the answer to the situation, post your thoughts in the comments section at the bottom of the blog. A few days after the post goes live, we'll add a new post with what we did and if that solved the problem or not. Remember, the answer may involve a technology component, but it will not be solved solely by technology.

COTS Implementation

Your CIO has recently received a great deal of negative feedback about one of the applications that nearly all of your internal customers use on a daily basis to complete their work. This application was developed internally and is highly customized for that business process and your organization. Most of this feedback focuses on the speed at which users can complete tasks and the age of the technology in question. Most stakeholders believe that a solution that uses newer technology that focuses on a touchscreen instead of keyboard entry would allow for faster throughput by users, resulting in a small labor savings and a large customer satisfaction increase.

Despite the dislike of the current system, its customizations and integrations with other corporate systems make it difficult to replace with a COTS (Commercial, Off The Shelf) product. Still, your CIO does not wish to develop another system internally when there are numerous COTS products that perform similar, if not exact, functions. You are instructed to initiate an RFQ (Request For Quote) process with the major vendors who have produce applications in this market.

Picking Up The Phone

You, being a person who keeps in touch with industry trends, know the major players in the market segment and start making phone calls with those vendors. Besides the standard information most vendors want to know, such as number of users, number of locations, operating systems used, etc, you also provide a list of functionality of your current system that you are looking to replace. You explain to the vendors that it is of critical importance that their systems replicate all functionality in your existing solution and that their product be able to interface to all your other internal systems.

As the vendor RFQs trickle in, you notice a disturbing trend... the cheapest of them is an order of magnitude greater in price than what it cost to develop and maintain the existing system since its implementation over a decade ago. While you know your legacy system is very specialized to your company, you are astounded as to the large number of development hours that will be needed for every one of the vendor systems to meet your needs.

Checking In

Now you are in a dilema... your CIO expects your findings to be on her desk by the end of the week and you know she won't be happy with the price tags on the RFQs. What do you say in your report? Is there anything you can suggest to help lower the prices? What could you have done differently in the RFQ process?

25 August 2010

Thinking with Hats

I have seen every brainstorming and idea generation method under the sun... or at least that's what I had thought until a meeting with my company's R&D team a few weeks back. The subject of the meeting itself isn't important to this post, but the method we used most certainly is. This method is not new, even though it was new to me, and presented an interesting take on the managing of a brainstorming session. Without further adieu, I give you Edward de Bono's Six Thinking Hats.

The Method Behind the Madness
Nothing in this methodology is amazingly new or surprisingly different. It follows the standard steps of framing a problem or opportunity, working up ideas to solve it or meet the need, poking holes in the solutions and then finding ways to plug the leaks you just created. What I did find of interest is the way the methodology forces a group to work through the process in a structured manner but doesn't necessarily stifle any creative inputs.
The basic idea is that the human brain thinks in very specific 'modes', or as de Bono would say, hats. Each hat is represented by a color and has a different meaning and function. Its not necessary to give everyone in the room 6 different colored physical hats to wear during the corresponding session, but its more of a way to keep everyone in the session focused on the goals of that particular hat. (For a great explanation of each hat color, see this Wikipedia article.)
The purpose of the session determines which hats get used, which get used more than once and in what order the hats are used. Idea generation, problem solving, strategic planning... there are many ways to combine the hats to reach a desired outcome.

The Good Stuff

One of the things I really like about this method is its structure. If you've ever been involved in a brainstorming session that ended up on a topic totally unrelated to the stated reason for the session, you understand the reason a methodology like de Bono's is needed.

Similarly, if you're in charge of a meeting with a large number of stakeholders who are easily distracted, disruptive or simply uncontrollable, using a structured methodology like this can improve the results of the session. Getting such a group to agree to adhere to the tennets of the process may prove difficult, but if they can buy in to it, you're that much closer to a successful conclusion.

The (Potential) Bad Stuff

Overly structuring a session can lead to a few negative consequences as well. While the six thinking hats are not an extremely rigid methodology, for a group that is comfortable with one another and already works well together, adding in a more formal set of guidelines such as these may temporarily derail output as people adjust to the new discussion norms.

Another potential downside is a stifling of creativity due to having an overly zealous 'traffic cop' who righteously knocks down any comments that don't pertain to the current 'hat' that is being worn by the team. Its one thing to keep a group on track, but the moderator must focus on reaching an objective more than just adhering to a given method.

Have you used the six thinking hats before? If so, let us know how it went down in the comments section. If you haven't used it, do you see how it might be useful in your organization?

23 August 2010

Lisa Crispin's test quadrants

On Wednesday’s our team checks into a meeting room and holds a tech talk.  Recently we have been watching videos from the NDC.

Lisa Crispin presented a video on testing approaches and put up a slide (p19) with a four box quadrant to help think about testing.  The quadrant axes are Business v Technical and Support the team v Test the product.

The developers on our team really liked the model.  It gave them a mental model on how it all hangs together.  I wasn't so much a fan so I challenged them on it.  I like my axes to be opposites and I felt that the support the team v test the product axes were not quite right.  I get the idea but wasn’t really sold on it as a useful model.  I thought the model Lisa presents is really a stack.  Take a look and see what you think.

Anyway, the devs talked and I listened and they explained that from the perspective it made a lot of sense. I had another look at it and decided to elaborate some of the ideas and try to make it my own.

The main goals for me are to make the axes the right ones without varying from Lisa's model to far.  I want the essence to stay the same but to get a better sense f the why, rather than simply the what and who of testing.

This is my attempt.  What do you think? Can this help you with your project’s test strategy?

20 August 2010

Reviewing Project Team Members, part 2

In the first part of this series, I focused on things people managers can do to improve the review process for employees who spend most of their time working on projects. This second part will focus on getting down to writing the review and then having a discussion about the review with your employee.

Putting Pen to Paper (or Fingers to Keyboard)

You’re busy. So is your employee. Don’t put this off until the last minute. The last thing you want is your employee telling you that getting their review complete isn’t going to happen because they’re in the final week of their project and they simply don’t have time to do it. Set the deadline early, make it consistently the same time from period to period and remind your employees to schedule time for it in their personal (or possibly even the project’s) plan.

If your employee has done exactly what is expected of them, don’t waste your time and theirs writing a page to say so. On target assessments really don’t rate a novella. If your employee has done exemplary or horrendous work, then say so in as firm a language as possible. If they’ve done only what was necessary for the moderate rating, then there is nothing more to say other than what they can do to achieve a higher rating.

One way your employee knows what to focus on in the next period is if you include goals for them to achieve in the next review period. Let your project team member know that you expect them to manage larger projects in the next cycle or that they will themselves be leading a small team of analysts.

Include as much hard data as you can. If you manage a team of testers and one tester regularly finds more defects than anyone else, list the number of defects found and the % of total found in their review. If a lengthy requirements document was accepted on the first pass with no only two minor changes, saving weeks worth of potential rework, make sure that effort is noted. These items make a good pairing when used with the ‘Naught or Nice’ list discussed in the first post in this series.

Conducting the review

After all of the specific project employee suggestions I had in previous sections, this last area is going to be surprisingly devoid of project specifics for this area. In many ways, reviews are simply another meeting which needs your attention. That said, do your best to not treat the time you are spending with your employee this way, even if deep down that’s how you feel about it. Do your best to fake it. Don’t be dishonest about it as your employees will easily catch any false enthusiasm you try to put forth, but make it as enjoyable, or as minimally painful, as you can. If you’re hating the time there, chances are that your employees feel the same.

Don’t waste time during the session. Have a plan for what has to be said and be flexible in everything else. I usually know how I am going to start the session, the key points I need to make during the review and what I am going to say to close it out. If it takes five minutes or fifty, I want those to be productive minutes and not a waste for either of us. If your employee has nothing to add once you’ve said what needs to be said, don’t just hang out, get out of there and get back to your projects.

Once all the requirements for the review have been met, it is then just a chat in a coffee shop with a friend. I am up front about it being an open discussion and any topic is fair game. I can’t always promise I can answer, but if I can’t answer, I at least tell them I can’t even if I can’t tell them why.

Before you both depart, get agreement on the review. They may not agree with your assessment, but get agreement on the disagreement at the least. If you do not agree, work on a plan for what you can both do to come to an agreement. Sometimes, hopefully very rarely, you can’t agree. In this case, remember that you are the manager and that they may just have to abide by your decision, no matter how much they object.

Lastly, get out there and get back to work! Its time to take what you’ve both learned from the review process and apply it to your project. Before you know it, you’ll be back in this room and you want the next conversation to be even better than this one.

18 August 2010

Reviewing Project Team Members, part 1

Probably the worst review I have ever received started off by my boss of 18 months saying, “Wow, if I had known you were doing this caliber of work all this time, I would have given you a much higher score.” Its no wonder why I was already in the middle of interviewing for a different job and ended up submitting my resignation just a few short weeks later. But it doesn’t have to be that way.

Recently I heard a news story on NPR about how companies should do away with employee reviews completely. I don’t know that I entirely agree with that sentiment, but I do understand the underlying frustration. Too many times in my life I have sat down across the table from my boss and thought this was just another way for them to deny me a raise or promotion. Thankfully I have been fortunate to have a few excellent managers that have more than balanced out the bad ones; people who make the review process much less painful.

Now that I’ve been a personnel manager for a few years, I feel that I have a few suggestions for you people managers out there on how we as project people could improve the reviews we give to our employees.

Involving a Business Analyst or Project Manager
Tie results directly to their respective body of knowledge (BOK). When your results are directly tied to the key measures of your job, areas which have received wide support and have stood the test of time, it makes the process feel less arbitrary and less of a popularity contest.

Encourage your employees to get involved in the process, just like they do in a project. If you manage business analysts, have them treat the review process like they would a lessons learned session, benchmarking their progress so that during the next iteration they can show improvement. Have your project managers make their review into a plan, with tasks to perform in order to be promoted.

Have your analysts learn a new elicitation technique during the year. Of the more than a dozen options, most analysts have only used 4 or 5 during their career. For project managers, learn a new project costing methodology.

He’s Making A List...
Santa kept one, and so should you. I’m not talking about a pet reindeer, but a Naughty or Nice list. I keep one for each of my employees in a folder on my computer. Whenever they do something especially good, or especially bad, I update the list. This makes it much easier to have quality information to include in the review, meaning you don’t have to spend a lot of time thinking of what to say.

If you’re managing shared resources, you’re often not the best person to be reporting on your employee’s daily activities. The product or process owner they are working for during the review period will usually have a better understanding of your employee’s performance than you do. Ask the people who your employees work for and with if there is anything they can think of that the employee has done in the last period that is especially noteworthy.

Before Its Too Late
Never get surprised during an evaluation. Never surprise your employee, either. If you walk out of the room and either person is wearing a shocked expression, you have done something incredibly wrong. If you wait until the review to bring up problems, you’re only creating more problems. Issues with employees need to be addressed on a timely manner, not just when you can get around to making an official record of it.

That is easier said than done. Many of us prefer to avoid conflict, but remember that putting off the confrontation only allows bad habits that much more time to be ingrained. Fixing it now is much easier than fixing it at the end of the year.

Its not just bad behavior that should be acknowledged immediately, but good behavior, too. If a PM comes in on time, on budget and on scope, make sure to recognize them publicly. If a BA produces a truly exceptional requirements document, circulate it around the office as an example of exactly how work should be done. If your company allows for it, presenting them with a small token of appreciation from the team can go a long way, especially in lean years like the ones we are in right now where pay raises and bonuses may be suspended.

Check back later in the week for the second half of this post, which focuses on writing the actual review and then having the conversation with your employee.

16 August 2010

Efficient Project Markets

Back in college, I was a finance major. Despite having never once used all those hours of studying and research as a part of my career, the concepts themselves stuck with me all the years since graduation. One concept in particular, the Efficient Markets Hypothesis, is something we’ve been hearing a lot about in the news since the start of the financial market ‘meltdown’ a couple years ago. Much of the debate has been about if the financial crisis invalidated or proved that markets really were efficient. Hearing all of the debate started me thinking about if projects represent efficient markets or not.

As a refresher for those of you who have forgotten your financial theory courses, or for those of you who were fortunate enough to avoid them, let me give you a very short review of the theory... it is impossible to make excess returns based on information that is available to everyone in the market. As soon as new information is generally released, all participants in the market immediately assimilate the information and make rational decisions based upon that data. While individual investors may not be rational, the market as a whole, which is made up of all investors, is rational as not everyone will be irrational at once.

(Note: I’m going to skip analysis of the three forms of market efficiency in hopes of not totally losing my audience. If you like this post, I can always go back later and discuss each of the three forms in relation to projects; all you have to do is ask.)

Those of us who work on projects understand that communication is a key element for project success. At one time or another, we’ve all had a coworker or stakeholder who is an information hoarder that believes knowledge is power and if they can accumulate enough knowledge, they’ll be untouchable. This strategy generally falls apart, especially in situations where the project is part of a strategic initiative or there are lots of people who are willing to share the information that the hoarder is trying to keep for themselves. In this way, a project is theoretically efficient, because once the knowledge is no longer exclusive to the source, then anyone involved in the project has access to that data.

So projects are efficient in that information is accessible, but what about that part regarding the market being rational as a whole? Does that stand up in project-land as well?

This is where I feel that projects tend to fall apart at being efficient, namely that the stakeholders and project members do not always regard the project with their own best interest. Sure, all employees in today’s work environment need to look out for themselves, and being on special projects is one way to prove your value to the organization, but often times the project is your red-headed step-child; that thing you deal with only when you don’t have pressing ‘real work’.

How many times have we walked into a project meeting only to find that no one has read the meeting pre-read? What about the number of times no one bothered to bring status updates to their project tasks? It happens considerably more often than it should. Its not that projects lack the ability to be efficient with information, but that stakeholders are often unwilling to provide enough rational ‘investment’ in the project to ensure its efficiency.

What can be learned from the research created in studying market efficiency that could be applied to our projects to help them have better information efficiency? The fact that so many research years (more like centuries at this point) have been put into studying the subject should tell us that one of the best ways to find inefficiencies in our project communication is to study our communication methods and modes to see what is working and what is not. If all of our communication is through one or two channels we should expand to additional methods to get our message out. If we perform irregular message blitzes, the problem is likely that our stakeholders don’t know that there is information they need to know.

As I referenced earlier in my aside about the three forms of efficiency, there are multiple ways to say that a market is efficient. Similarly, there are multiple ways to perceive that the communication of information in a project is efficient. People’s need for information is different based upon how the project impacts them and their job. It is a good idea to segment your communications, by frequency or by depth of information, and match that to communication to its intended audience.

Lastly, realize that there will always be critics. As the efficient market hypothesis has garnered a whole new round of criticism in this era of financial turbulence, so to will your projects be hit with waves of upheaval when it seems that things were going so very smoothly. Make sure that you identify risks that could upset your project’s information symmetry and plan your responses accordingly. Make sure that if you don’t have an up to the minute status report, you know the quickest path to the needed information and can place the knowledge in your stakeholders hands with a minimal amount of wait time. Updated project plans, a clear sprint backlog or even a listing of bugs resolved in the last week could be just the information you need to ease the concerns of your stakeholders.

Are there any other finance majors turned project people out there? What are your thoughts on the lessons of efficient markets and projects?

13 August 2010

Document Best If Implemented By The Date On The Cover

There is a great scene in the movie 'Clerks' where a woman is going through every single gallon jug of milk in the store, checking to see if which one has the expiration date that is the furthest out into the future. The clerks behind the counter muse that its as if she's looking for a magical gallon of milk that will never expire.

I often wonder if requirements documents should come with a similar expiration date. I have lost count of the number of times when I created a requirements document and had achieved sign-off, only to have the project delayed for months or years. When the project started back up the following year (or years), we were right back at square one, revising, updating and sometimes scrapping and rewriting the entire document.

Stakeholders remember signing off on that document years ago and occasionally ask why we can't just use what we already did. Why do we have to 'reinvent the wheel' when there is a perfectly good document which has all their needs outlined in it, just sitting on a shelf collecting dust???

It can be a painful conversation to explain that the impacted systems and business processes have not stayed the same during the interm time since the document was signed. The business environment, even in a relatively static market, has likely changed in some way that invalidated some requirements and caused other requirements to be brought forward. Priorities for requirements may have changed as what used to be the customer's primary goal is no longer even a consideration when looking to purchase a product or service.

It is with these types of conversations in mind that I begin to think that an expiration date on a requirements document would be a very good thing. The date listed would be the timeframe in which the requirements document could be implemented without the need for major review of the information contained within the document. So how would we go about setting such a date?

I think there are several factors that would all go into making such a date. First, what is the duration of the project implementation if we started development on the day the document received sign-off. This could be the minimum date into the future in which the document is still valid. But what about change requests to the requirements that happen during the project implementation phase? Do those not implicitly invalidate the document already? Possibly, but they could also represent additional requirements or additional detail to existing requirements that do not necessarily invalidate what has already been elicited.

Another problem with using the implementation duration is that, especially in the case of large waterfall projects, the timeline can be excessively long. The first project I ever worked on had elicited requirements 18 months before I joined the team and didn't end up fully implementing those requirements until 6 years later. An 8 year timeline between initial elicitation and eventual implementation meant that much had changed in the industry, resulting in a raft of changes to the original document. Thankfully the original document did expire in this scenario, because if we had implemented what was originally elicited, we would not have been nearly as successful.

So, we've got a potential minimum date, but that doesn't necessarily mean the requirements would not still be valid for some timeframe after that date. There are two more factors which I suggest could help push the date out further.

The first is the rule of the 3 C's: correctness, completeness and complexity. If you're confident that the document is correct and complete plus the requirements are not complex, then the timeframe over which you can probably implement the document without needing to do more than a cursory review of the existing requirements.

The second reason that could allow you to push the date out further into the future is the stability of the business environment. This is probably the most difficult variable as markets that have been relatively stable for years or decades can be turned upside down in moments. It is often difficult, when in the midst of such upheaval, to really know you're caught in the middle of radical change. Businesses often react to change like this instead of anticipating. This negative response can be compounded by the person who remembers that old requirements document which will 'fix' the business when implemented, who dusts it off and touts it as a savior, only to find out after implementation that they just solved a problem that no longer exists.

Its hard, when caught in the middle of such business strife, to not look for a savior in something you've been wanting to do for a long time. You've had it in your mind that this project would solve all your problems, even if it would only solve those problems you had 5 years ago and not the ones you have today. A turbulent market is not the time to go without proper analysis and to simply implement something that is meant to solve a different problem.

Could your requirements documents use a 'best if implemented by' date? What are some other factors that could influence how you set such a date?

11 August 2010

Scrum 18 months on

I have been with my current team for just over 2 years.  I was hired to bring in a troubled project using agile techniques (likely scrum.)

We started out together in state where we weren't really ready to switch across fully, but the team were already applying some scrum/agile practices and making some headway against the systemic problems that had held them back in the past.

It was January last year when we went across to vanilla scrum and started following the manual by the book.  Soon after we kicked this off we added a bunch of quality related practices from the agile play book and the team continued over time to become more and more effective.

Tomorrow (as I write) I am having a session with the team revisiting the basics of scrum for two reasons; the project has changed and so has the team.  While there is nobody new on the team we have lost some people at the end of the last project and there is some uncertainty about roles and goals in our new context.

So - a refresher, not an intro to scrum.

The below deck contains some talking points, some exercises and some worksheets that I am going to use to see where we need to change.

If you find it interesting I'd love to hear your comments.  If you have had a similar session with your team I am also very interested to hear how it went.

9 August 2010

Project Misconceptions

We've all had that stakeholder or that developer or that analyst who had a single viewpoint on what they saw as the truth of a problem. No matter how much data you showed them, no matter how many better informed people contradicted them and no matter how many logical points you brought up to them, they would not believe differently. Sometimes we put such belief down as 'ignorance' or maybe even 'stupidity' and it is difficult for us to fully understand why the other party is unwilling to change their mind.

When I saw this article on NPR's website, I immediately saw how this applies to projects as well as politics. Brendan Nyhan, a health policy researcher at the University of Michigan, published "When Corrections Fail: Ther Persistence of Political Misperceptions." I suggest you check out the entire article, but I posted some of my favorite exchanges from the interview for you below to give you a taste of the goodness it contains:


Mr. BRENDAN NYHAN (Robert Wood Johnson Scholar in Health Policy Research, University of Michigan): Thanks for having me.

CONAN: And when facts are readily available, why are they not enough to change people's minds?

Mr. NYHAN: Well, the problem is, you know, as human beings, we want to believe, you know, the things that we already believe. And so when you hear some information that contradicts your pre-existing views, unfortunately, what we tend to do is think of why we believed those things in the first place.

And, you know, so when, you know, we get these corrections, we tend to say I'm right, and I'm going to stick with my view. And the thing that my research, which is with Jason Reifler at Georgia State University, found is that in some cases, that corrective information can actually make the problem worse...

CONAN: This is a phenomenon described as backfire. You say it's a natural defense mechanism to avoid cognitive dissonance...So this isn't a question of education, necessarily, or sophistication. It's really about, it's really about preserving that belief that we initially held.

CONAN: And you define sophistication, as I read your piece, you define it as somebody who is right a lot of the time, but the 10 percent of the time they're wrong, boy, they stick to being wrong...

Brendan Nyhan, why is it that highly partisan issues seem to be most subject to this backfire phenomenon?

Mr. NYHAN: Well, I think they're the cases where people care most about the actual outcome of the debate....

Mr. NYHAN: of the things that I've advocated is holding elites responsible for putting this information out there in the first place, and the kind of fact-checking that Dana has done is one way to do that. And even if it isn't effective at changing people's minds out there, maybe it makes people think twice about putting the information out there in the first place.

CONAN: And Dana, that suggests that there is a, you know, the shame factor: If you can hold the elites responsible for putting out information that's just, well, flat wrong, maybe they can then tell their supporters I might have missed that one.

Mr. MILBANK: Well, I think it's useful to attempt to do that. I'm kind of doubtful that it actually has any effect....


I don't necessarily agree with Brendan that 'shaming' can be used successfully, especially in a project where people have to work with one another every day after such an event would occur, but I see that there are some fascinating impacts this type of research has on how we, as project people, work with each other and our stakeholders.

7 August 2010

Just because your project isn't on the strategic plan doesn't mean it's not strategic.

You may have to search for the link though.

The idea: not all opportunities are recognised up front. Much of what the enterprise does is keep up with the Joneses.

Occasionally through the housekeeping projects new capabilities and opportunities are discovered.

How can your project do more than just deliver on time?

6 August 2010

Is the Future in Insourcing?

Don Dodge is awesome. This guy really gets me to thinking. An article he posted to his blog today sparked a thought about what it might take for the 'western world' to bring back jobs that those of us who spend our time working on projects helped to outsource over the last decade. I've always had a problem with the term 'low cost labor' but the reason why never clicked until Don pointed it out.

Its not that the labor in these 'low cost' countries is any cheaper than it was in prior decades, its just that the cost of transporting raw goods to those countries and then transporting finished goods back here is so much cheaper and easier than it once would have been.

We know that oil will not last forever. Almost every form of alternative energy that is currently possible has at least one major limitation. At some point we will either 1) develop a new (or make an existing form commercially viable) alternative energy source or 2) transportation costs will increase to the point where travel will no longer be as cheap and easy as it is right now.

Assuming that option 1 does not occur and that option 2 does occur, our world will now be at an interesting place. The developed world would once again need to begin manufacturing its own goods, meaning a possible return to an economy that is more similar to the one we had in the 1950s... but with a twist.

The people, like us as project members, who don't directly supervise the workers who directly make things, will either need to move into close proximity to our places of work, or we'll need to rely even more on telecommuting. Given that energy costs will likely be spiking for other forms of energy at this time as well (scarcity of one will cause greater demand for other forms, and thus scarcity of those forms as well), employers will wish to shift as much cost away from themselves as possible. Having project teams work remotely from their own homes, requiring team members to pay their own internet and heating/cooling costs, not to mention space in general and office supplies, will fall into the 'cut every cost you can' priority list.

Projects of the Future

But its the projects I see us working on, or at least our successors if we are fortunate enough to have saved enough to retire by this time, that fascinate me. Just as project people can work from home, so why couldn't the whole telecom services segment work from home as well? Imagine, instead of having a large number of call center reps onsite with their data center (or with a massive pipe into a hosted center), everyone has a relatively small pipe into their own house's data center. How would that change the requirements for hosted applications?

Its not just software projects, but business processes that would need to change drastically. Think about large shipping companies like UPS and FedEx. Already these companies do everything they can to avoid costs due to fuel and labor, utilizing large software applications to plan routes that take more right turns than left so that vehicles are left idling for less time in traffic. Now what will these companies ask of their business planners who see package traffic moving back to rail or even going by river traffic. It sounds absurd, but a boat flowing downriver takes a lot less energy than does the fleet of trucks traveling on the interstate next to the river.

What about you? What types of interesting projects do you forse if such a transport-starved future were to occur?

5 August 2010

Better Projects now smartphone enabled.

Thanks to Ray Claridge's Tester Troubles blog I knew there was a simple and easy way to present Better in a smartphone browser.

Less than 5 minutes and it's now enabled.  Test me out.  Open your fancy phone and search for Better Projects.  

See how great this is?  Now when you want to open a Twitter or RSS link to this site on your phone it's going to be better than ever.

Scrum Butt and the Nokia test

I just took another look at Schwaber’s Nokia test and observe the trends in scrum practice patterns over the two test periods. Like any packaged product scrum is elaborated and adjusted over time, but you have to ask, are the changes positive, negative or inconsequential.

The scrum leadership are a little schizophrenic on the matter of adaptation. One the one hand, maintain the basics of scrum to yield the benefits of an integrated approach. On the other hand – it’s a framework with an “inspect and adapt” mechanism built right in.

What should you do?

4 August 2010

A Day In My Life

I've been thinking about doing a blog post for a while now that chronicles my day as a BA. Below you'll see my timeline from when I got to work until the time I left. For obvious reasons in protecting confidential information for my employer, I won't be giving specific details about projects, but I think its an interesting overview of what I do every day.

7:45am = Arrive at work. Wake up the computers and realize that of my two, neither applied overnight all the Microsoft patches for this month. Promptly reboot. The desktop booted and was back up in under 5 minutes. The laptop, which also serves as my email machine, was usable 20 minutes later. You have to love old hardware with lots of boot processes running. While I'm waiting for the laptop to boot, I use the desktop to check up on what technology news hit in the overnight hours. My news reader cleared, its time to get down to work.

8:00am = Check my work spam filter. Looks like I've only got one support issue stuck in it. I release it and 5 minutes later, once the laptop is up and going, check out what happened. Looks like a misconfiguration in a system, so I update the setting, email the person back and let them know the problem is resolved.

8:10am = Begin the gauntlet of vendor emails. None of them are exceedingly difficult, just numerous. I respond to each, giving out information as needed and making decisions as required.

8:50am = Walk down to the helpdesk in search of one of my stakeholders. Turns out he's at team standup, which happens every day at 8:45am, but I forgot to look at the clock before walking down the hallway. My mistake, I'll come back later. Spend a few minutes with a technician gathering some data to take back to my desk and email to another vendor.

9:00am = Vendor emails complete. Open up the new requirements simulation tool I've been tinkering with for a few months and spend a little time learning a few new things. The tool seems to be very thorough in its capabilities and functions, but the documentation is sorely lacking. The company website is no help, either, as the tool is a freebie meant to entice organizations into purchasing the more robust products they sell. They have no incentive to provide documentation on how to use their free product as they want you to buy something that has lots of documentation. Sad. Despite this, I do manage to uncover a few items I had not yet realized were there and my respect for the designers of the tool increased. I'm thinking that after years of looking for a requirements tool that meets my needs, I am closer than I have ever been to finding one.

9:30am = Try my walk to the helpdesk again. My stakeholder happens to be in a deep conversation with one of his team members about an upcoming project that will impact that team member's team. I watch someone who is quite skilled at allaying fears work his magic. He eloquently points out that those in a support role such as theirs can raise red flags when they see problems and escalate to their management, but they will be unable to effect change on their own. Its a frustrating position to be in and he expresses his understanding of the feelings of the team member and helps them to understand it isn't their fault nor will they be held accountable if the project does have issues at the time of go-live. Its always good for me to be reminded that, even if it isn't about a project I'm currently working on, my work has a real and lasting impact, hopefully for good, on many people. It is at my own peril that I take the fears of those people lightly.

Once that conversation is complete, my stakeholder and I move into his office to discuss a voicemail that landed on me at quitting time the prior day. I didn't understand why he was involved but wanted to ensure we were not working at cross purposes nor were we duplicating efforts. We rehash his involvement and determine a course to take from there.

Our conversation then turned to some changes occurring in some of my own projects. Because his teams are responsible for all the work my team produces, I wanted his thoughts on how those changes might impact his team. He has been a fixture in the company for many years and is an incredible wealth of knowledge regarding political and policy decisions made over the last decade and a half. Besides the historical underpinnings for decisions, he also provides an immense knowledge base for operational issues and can make recommendations that almost always pan out correctly.

10:15am = Return to my desk. Check the area code of that vmail from the previous day and realize I will have to wait until after lunch to return that phone call. Notice that in my absence, I have another vmail. This time it is a PM with a question about some research I've been doing on the side. Turns out his boss' boss wants additional information. We kick around ideas for a while and come up with a strategy. I fire up the SQL editor, modify a query and pull back another revision of this custom report.

10:30am = Look through my open item backlog and begin to sift the pages of completed items and find any thing that might still be open. I notice one I wrote down last Friday that was waiting until a developer returned from vacation. I walk a couple isles over, spend 15 minutes discussing an enhancement request with the developer. He's receptive and will put it on the list. He asks me if I would ask a couple of stakeholders about another idea he had to see if they like it and what tweaks they might want. I add another item to my to-do list in place of the one I just checked off. I review his most recent work, make a couple suggestions on the size of some controls (I'm a UX expert on the side, not really) and congratulate him on an otherwise very nice job.

10:50am = Back at my desk. IM the QA team to see if we're going out on our usual Thursday lunch. We are. I then begin the creation of a pro/con and potential enhancement list for an existing product that my team develops. Work on this until going to lunch at a little after noon.

1:10pm = Arrive back from lunch, much refreshed from good conversation with good people. I make that call to the west coast and spend a while talking with that client. The call turns into an impromptu conference between a couple different customers. We talk requirements and process, I hang up and wait for them to email me more information.

2:00pm = Start back on the pro/con list, only to be interrupted by a ringing phone 5 minutes into it. Its the PM again, wanting additional revisions to the data. SQL editor, some changes, a new file emailed and 15 minutes gone.

2:20pm = Start back on the pro/con list. Interrupted by a stakeholder at my cubicle who is looking for the manager that sits across from me who is nowhere to be found. He hangs out, talking through other questions he just happened to have for me until the missing manager returns 15 minutes later.

2:35pm = Start back on the pro/con list. 5 minutes later the phone rings again. Its my PM and guess what? Round 3 of changes today. SQL editor, some changes, a new file emailed and another 15 minutes gone.

2:50pm = Start back on the pro/con list. 10 minutes later the phone rings yet again. My boss this time. Time for my mid-year review. I spend the next 15 minutes talking about my work the first half of the year. Things are all good and we then spend the remaining part of the hour discussing upcoming projects and the status of current projects. Good thing I brought my trusty notebook because I pick up 2 more action items.

4:00pm = Cross off one of my action items by catching a colleague on his way out the door. Monopolize 2 minutes of his time answering some questions, delaying his departure for the day. Hey, I'm not leaving yet, so why should he? (Kidding.)

4:10pm = Back at my desk. Yes, you guessed it, there is a vmail from my PM. Round 4 of changes to the data. Same process as last time. While I'm making the changes, the email I asked for during my 1pm conference call finally arrives, but there is nothing I can do about it until tomorrow anyway. Do a quick review of the email with the boss.

4:20pm = Back at my desk, once again starting on that pro/con list. Five minutes later, another vendor email pops up, this time with a dozen questions that need to be answered right now, most of which I had answered multiple times in the past. Spend 20 minutes replying, get an immediate request for clarification, send a response and the phone rings immediately. Spend another 10 minutes talking on the phone with the vendor trying to resolve a process issue. Add another two items to my task list.

4:50pm = Play phone tag with a finance stakeholder trying to answer one of my action items. Eventually catch her as 5pm is reached and hang out until 5:15pm working through a couple of my action items. I write notes to myself on the whiteboard for tomorrow morning and call it a day.

So that was my day. It was a fairly regular one, even if I did get interrupted probably more often than normal. What do your days look like? Let us know in the comments

2 August 2010

Are Requirements Really This Messed Up?

Call me skeptical, but I find it increasingly difficult to believe that 'bad requirements' are at the heart of so many failed projects. Over the last couple of decades, there have been numerous studies released that declare poor requirements to be the root cause of most software implementations failing to return value. Depending upon the source, the percentage of failed projects due to poor requirements can be anywhere from 13-40%.

If so many publications out there, from the Standish Group Chaos Report to Gartner to CIO are saying the same thing, why do I have such a difficult time in believing them? Why do I read articles such as those linked to in the last sentence and have a difficult time accepting their conclusions? Are these not research companies who are paid to study these kinds of issues and report on them to you and I? Do they not stake their reputation on helping companies find and fix the root causes of their project problems?

Digging Into The Studies

Lets use the Standish report as an example. Go grab a copy and read it. At the beginning it sounds so wonderfully meticulous with estimates based on the number of projects that failed, the size of those failures and the unreturned value on investment. These numbers all seem to make a lot of sense and paint a very grim picture for those of us who work on projects.

Where the analysis in the report begins to turn away from what I see as reality is when you hit the word 'survey'. How did Standish come up with their results? They asked people to tell them. Lots of people mind you, but still people. Surveys can tell you a lot, but at best they can give you only a directional guide as to the real problems. Surveys are full of issues, one of the biggest being that people who respond are ultimately not very honest with their responses. Its called a self-reporting bias.

Standish surveyed CIOs and other IT leaders and asked why projects failed. I feel the need to point out a few different failures in their approach. First, who says IT leaders actually know and understand the root causes? How many times have you heard a CIO, who was not involved in the day to day routine of a project, stand up and talk about the project and get just about every salient point wrong? If you're like me, you've lost count. What makes anyone think a CIO, no matter how competent, knows the root cause of all the projects under their domain? I'm not saying that they shouldn't know, only that they are people and often don't come to the same conclusions as those who are active participants in the projects. Why did Standish not ask a less homogenous group of individuals as to their insight as to the project failure? Would this not have produced a less biased means of determining failure?

The next failure in the study, as I see it, is in the wording of the reported problem... requirements. What exactly does this mean? Are these business requirements or technical requirements? What about implementation requirements? Just calling something a 'requirement' and pointing a finger at it does not a villain make.

The Standish results state that only 2 of the top 10 reasons in the Project Success Profile had anything to do with staffing and those reasons made up less than 10% of the entire reasons reported for success. For the Project Impaired Profile, not a single one of the 10 items reported a staffing issue other than a lack of sufficient resources. It is difficult for me to believe that the largest expenditure on most projects is for labor and yet almost no blame ever rests on the shoulders of those who are actively involved in the project. Very few executives would be willing to poke out a finger and say, "There's the reason we failed; that person in cubicle C3-476." While a single person generally cannot torpedo an entire project, a group of people most definitely can do such damage. Most people would not intentionally do such damage, but unintentionally or simply carelessly could do such damage. It simply seems strange to me, and thus makes the results of the study seem to be flawed that this wasn't even a reason in the top 10.

(That last statement feels a bit self-damning given that I spend 90%+ of my time as a project team member. Believe me, I do feel the pain of my own project failures quite keenly, but most importantly, I learn from them and rarely make that mistake ever again.)

My last issue with reports like Standish is that they seemingly never take the time to do much more than talk with people. I am an analyst by trade. It is my job to spend days poking holes and generally getting to the root cause of problems and opportunities. Why did Standish not do the same? Why did they not do a better job of doing objective, root cause analysis instead of just taking the word of a group of industry insiders?

Contrast this with the work done by researchers like Jim Collins in his books Good to Great and Built to Last. Here is a guy who did more than just survey some people to find a convenient answer. He spent years digging into the details to really understand what makes a success and what makes a failure. What I want to know is why Standish and others like them only skimmed the surface with their analysis, never going deeper than a few inches into a problem that seems as deep as the Mariana Trench? Why was there no follow-up study to answer the questions I've put forth here?


If you've read this far, and for those who have I do apologize for sounding overly judgmental at times, but why do we continue to trust in these publications when their methodology seems flawed. I have lost count of the number of times I have heard someone quote one of these studies as a reason to 'fix' our requirements. It is not possible to fix something if you are unable to determine the cause of the failure. Its like saying that my car won't start so there must be something wrong with the engine. Yes, that's likely true, but the engine is a fairly large and complex piece of machinery, just like a project, and without deep study its not always easy to find the real culprit.

But most importantly, what do we need to do to fix the problem of project failure? Many studies have suggested different project methodologies or changes in team structure as the answers to project failures. Sometimes we hear that better or different training is required. Here again, we get answers, but no specific guidance on why these solutions will fix our project failure problems. If we're ever going to get better at what we do, we need a better study of the problem to provide a better set of answers.

(If you happen to work for one of the organizations I named above, please don't take offense at my statements as I want you to prove me wrong. In the future, I ask that you not only go deeper in your analysis, but explain your methodology in more detail in the document itself. If you think no one cares about your methodology, you're wrong. Make it an appendix if you have to, but show me the data and show me the care you put into designing a study that works around the flaws I have pointed out. I don't care how good your reputation is, I want to know what you did and how. The US Food and Drug Administration doesn't let drug companies off without showing their data and I will hold you to at least the same standard.)