Thanks to Ray Claridge's Tester Troubles blog I knew there was a simple and easy way to present Better Projects.net 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.var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E")); try{var pageTracker = _gat._getTracker("UA-xxxxxx-x");pageTracker._trackPageview();} catch(err) {} var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));try {var pageTracker = _gat._getTracker("UA-4191072-4");pageTracker._trackPageview();} catch(err) {}

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?

var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E")); try{var pageTracker = _gat._getTracker("UA-xxxxxx-x");pageTracker._trackPageview();} catch(err) {} var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));try {var pageTracker = _gat._getTracker("UA-4191072-4");pageTracker._trackPageview();} catch(err) {}

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

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%.var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E")); try{var pageTracker = _gat._getTracker("UA-xxxxxx-x");pageTracker._trackPageview();} catch(err) {} var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));try {var pageTracker = _gat._getTracker("UA-4191072-4");pageTracker._trackPageview();} catch(err) {}

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?
Conclusions
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.)

I dislike giving out immediate answers when someone comes with me to help them solve a difficult problem. Sure, I can give you a quick answer which may or may not be the best possible answer, and possibly may not even be a good answer, but difficult problems deserve plenty of time and numerous thoughts before they should be solved.var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E")); try{var pageTracker = _gat._getTracker("UA-xxxxxx-x");pageTracker._trackPageview();} catch(err) {} var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));try {var pageTracker = _gat._getTracker("UA-4191072-4");pageTracker._trackPageview();} catch(err) {}

Albert Einstein's general relativity was developed from 1907 to 1915, not in the blink of an eye. Yes, it is unlikely that any of us will ever encounter any problem which would require thinking of that deep and sustained nature, but that does not mean we will not combat and conquer only easily solved problems.
When I need to do my heavy thinking, I go to sleep. More precisely, I lay down in bed and let my mind take a meandering path through the problem space. I uncouple the 'obvious' linkages within the problem and see what happens when I couple items which would normally make an unimaginable combination. Its during these times of free association that I regularly hit upon a solution to my most difficult issues.
When I read a blog post by Paul Graham about The Top Idea in Your Mind, I instantly understood where he was going in reference to his morning shower. His best thinking is done there, just as mine is done in the minutes (and sometimes hours) between laying down and falling asleep.
As a child, I was raised in a Baptist church. One of my youth ministers claimed that reading the Bible as the first act of the day was vitally important for everyone and is something he wanted all the youth to do every day. As a means of 'encouragement', he once set up a phone tree so that the youth such as myself who were NOT morning people would be called every 2 minutes by the youth who were morning people to remind us to get out of bed.
I bring up that story as a way to show that sometimes even the best of intentions cannot produce quality results. Just like I could never do quality thinking in the morning like Paul Graham does, it is unlikely that he could ever do his deep thinking as he fell asleep in bed.
To give a fair assessment to problems my stakeholders bring, I generally ask them to let me sleep on it first so I can give them the best answer possible. My stakeholders know this about me and I believe they respect me for it, mostly because they keep coming to me for answers.
What about you? Where and when do you do your best thinking?

Hi, I am your completely random post for the week.var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E")); try{var pageTracker = _gat._getTracker("UA-xxxxxx-x");pageTracker._trackPageview();} catch(err) {} var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));try {var pageTracker = _gat._getTracker("UA-4191072-4");pageTracker._trackPageview();} catch(err) {}

Two weekends ago, I was introduced to a new musical artist and became immediately enthralled by his work. I was a music major for my first two years in college, so me becoming infatuated with an album or artist isn't really all that uncommon.
What is interesting about this artist is that the mood of the music did not in any way fit my life at this moment. Usually I find that new music which really resonates in some way draws a connection to the experiences and emotions found in my life at the current time. It wasn't until an event at my office several days later that I found out why this music would end up being so important to me. In fact, I don't know that I'll ever be able to listen to this artist again without thinking of this situation.
This is not the first time for this to happen to me, either. Back in September 2005, I was helping to support a large rollout in Europe. I spent essentially the entire month in France, with the last week of that trip as the only person from the US. By that point, I had spent months of my life shuttling back and forth between the US corporate headquarters and the EMEA headquarters, so while I was very familiar with my location, it ended up being one of the most lonely times of all my nine trips.
At that same time, Green Day's "Wake me up when September Ends" song from their American Idiot album was extremely popular. Prior to leaving on that trip, a friend had given me a gift of that album. The last week of September 2005 ended up being forever matched with that album. More specifically with a little Irish pub in downtown Orleans, France, where I sat alone at a small corner bar, wondering why I was spending my life on a project that had abandoned me in a foreign country. It was this event which sparked my eventual departure from that project and that company. This song and album are inalterably linked in my mind with loneliness and separation due to a specific project.
A happier event, months before that lonely September 2005 evening, a different song became linked with that same project. It was a much happier time, with the project in an earlier time. Our project manager had declared 'Funk Fridays' and would play all types of Funk music in his office on that day of the week. Normally he had headphones on to partake in his funkiness, but one particular Friday he failed to properly plug in his headset and was unaware that the loud music was coming from the laptop speakers and not his headphones. As the Commodores 'Brick House' blared out of his office door, most of the team gathered to watch as he jumped, jived and whaled from his desk chair. Only after a few minutes of squelched laughter in the hallway did he notice his audience. He was mildly embarrassed over the event, but it became a running gag to find out what he was listening to every Friday.
So what about you? What memories do you have of specific music being tied to specific projects?

• This is a summary of my experience at  BA World, Melbourne 19-20 July
• Recommend: Go to BA World Sydney on 17-18 August

I went to the Business Analyst World Conference in Melbourne on the 19th and 20th of July. Like last year it was a great event.  On day 1 I spent the whole day in one room (introducing speakers.) and got to listen to three very different stories.

Matthew Coppola from Perth training outfit Paramount Training gave a talk on Understanding Strategic Planning.

It’s always useful advice to go back to basics: Where do you want to be? Do you understand your capability? Mathew’s talk gave a simple framework to drill into these two questions. (See a transcripts of the whole talk here.)

Something that struck me while listening to his talk is how odd the world is. So many of us profess to know this stuff, but when you get out into the pressure of deadlines and complicated personal relationships – how many of us stick to the agenda and define the problem sufficiently before getting into implementation mode.

The second talk I saw was by John MacLeod of IBM’s Rational team on Steps to Better Requirements Management. This was the basics of requirements management: Start with a technology neutral business requirement statement, evolve it into a solution constrained by a particular IT or system scope and finally resolve it into specific statements of functionality. And trace things from front to back to keep up with what is getting done and what isn’t.

The third talk was a case study of a project delivered in NSW police by Peter Stanford of Artefaction called Architecting change – from Here to Eternity, or Agile and Now. This talk centred around the problems of getting consensus on big decisions in large, complex and diffuse organizations. The guts of the answer seemed to be making the decisions frequent and small, and using prototypes wherever possible.

On Day 2 I filled in for Paul Culmsee who was unable to attend – and did an ‘intimate’ Q&A session for two tables of people who wanted to ask questions about implementing agile practices. Matt Hodgson and Peter Stanford also sat in answering questions. It was fun and the people there seemed to like the more interactive nature of a conversation over yet another lecture.

The rest of the session was really interesting with lots of good content and speakers. I was happy I went and recommend anyone in Australia (or NZ) to pop along to the Sydney event on the 17th and 18th of August.

A few weeks ago I mentioned some colleagues and I were going to start up a local IT meet-up.var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E")); try{var pageTracker = _gat._getTracker("UA-xxxxxx-x");pageTracker._trackPageview();} catch(err) {} var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));try {var pageTracker = _gat._getTracker("UA-4191072-4");pageTracker._trackPageview();} catch(err) {}
We've committed to a date (17th August) and a location (Jack's Bar and Grill at Erina.)
So now there is a first event, a venue, a blog and even a twitter account (which eventually I'll get working so it posts from the blog.)
Now all we need is some people to come along.  
That's where we need YOUR help.

What can I say - I am a fan and you need to be as well. 
Go and sign up for the email udpates/facebook fandom/RSS or whatever is your flavour of keeping up.var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E")); try{var pageTracker = _gat._getTracker("UA-xxxxxx-x");pageTracker._trackPageview();} catch(err) {} var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));try {var pageTracker = _gat._getTracker("UA-4191072-4");pageTracker._trackPageview();} catch(err) {}

One of my early clients taught me how to not manage invoices in a company. This department's policy was that if any customer's submitted payment was more than $1 less than the amount on the original invoice, then the company would deposit the payment and reinvoice the customer for the remaining balance. Any payment short $1 or less had the remainder written off as bad debt and the check cashed. On the surface, this sounds like a fairly sound policy, but when you dig into it further, you realize there were a few problems.var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E")); try{var pageTracker = _gat._getTracker("UA-xxxxxx-x");pageTracker._trackPageview();} catch(err) {} var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));try {var pageTracker = _gat._getTracker("UA-4191072-4");pageTracker._trackPageview();} catch(err) {}

First, this company processed thousands of invoices per year with values for as little as $30 up to invoices that were over $1M. During the three years of history I reviewed, the company had only written off maybe $50 in bad debt. Contrast that with the hundreds of invoices they sent back out to customers requesting the missing funds for invoices that were short more than $1. In the grand scheme of things, it seems as if they do a really good job of collecting on their debt. That's a good thing, right? Well, maybe.

Consider if you will that a customer who paid $29 for a $30 product received the product at what is essentially a 3.3% discount, but the customer who purchased enough product to total over $1M would receive a 'discount' of 0.0001%. Seems a bit odd when put in these terms.

But it doesn't stop there. When you dig further into the numbers, you see that the customer purchasing at $30 was essentially a one-time purchaser but the $1M customer purchased year after year after year. Doesn't it seem like a bad policy in terms of customer service to reject an invoice over $1.01 when the entire purchase is over $1M?

Now, you've reached this point and some of you are probably screaming and banging on your keyboards, "NO! You must have standards!!!" and I totally agree! I just call in to question if this particular standard was a good one or not.

Let me add one more statistic that was floating around our project team... the cost for the company to produce an invoice, mail it and process the return payment. Anyone want to guess what this cost was? It was $12. So, you've got a company that is willing to spend $12 to collect anything from $1 to $11.99 and lose money on the entire deal. When you total up all the costs to recoup the missing revenue, you find that the company was losing a significant amount of money just in managing their A/R to this level.

Eventually, we did convince the department to make a change, but it wasn't one we found satisfactory. Instead of $1 being the threshold, it became $5. It wasn't the change that we wanted, but in the end it was the most that the company was willing to budge on the policy. In a way, we had a win, but to this day I wonder if that policy is still in place and if so, how much money they continue to lose with bad policies.

What are some of the bad policies you've seen in your time? Let us know in the comments!

There was yet another good post out of my news reader today that brought to my attention the following image:var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E")); try{var pageTracker = _gat._getTracker("UA-xxxxxx-x");pageTracker._trackPageview();} catch(err) {} var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));try {var pageTracker = _gat._getTracker("UA-4191072-4");pageTracker._trackPageview();} catch(err) {}


What I find so interesting about this is its simplicity as a task manager. There is no project plan here. There's no fancy program to tell you what to do and in what order. This is simply a desktop wallpaper where you drop documents you need to work on or other items of regular use. You don't need any elaborate filing system, you just find what needs to be done and do it.
My computers generally have very tidy desktops. I don't tend to be someone who lives with a lot of clutter, but on occasion, when I'm in the middle of several projects, such an organization strategy could help any individual task from getting lost amongst a noisy picture of some place I went on vacation years ago.
What about you? Besides pen and paper, your inbox or a project plan, what strategies do you use to manage your tasks?

This video popped up in my news reader and I thought I would share it as an idea starter. When was the last time you failed? What lessons did you take away from that failure? What habits have you made since then that will keep you from failing in the same way again?


var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E")); try{var pageTracker = _gat._getTracker("UA-xxxxxx-x");pageTracker._trackPageview();} catch(err) {} var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));try {var pageTracker = _gat._getTracker("UA-4191072-4");pageTracker._trackPageview();} catch(err) {}

BA World conference ends with a discussion on building organisational competency.

Here is my question; Does 'professionalisation' help or hinder the broader goals of the org?

Published with Blogger-droid v1.4.8

I love everything about wine. From the vineyard to the glass, the entire process simply fascinates me. I love talking about grape varieties, soil composition, weather patterns, oaked v/s steel, yeast, racking, bottling… the list just goes on and on. If you know anyone like me, or are yourself a fan of wine, you’ll know that there are lots of terms that are used by wine snobs that you’re not likely to hear anywhere else. There is a completely new vocabulary to learn if you want to be thought of as a wine connoisseur by your friends.

The same thing can be said for working on projects. We talk about project plans, predecessors and successors, KPIs, functional requirements, burn down charts, RACI matrix and requirements elicitation. These are terms that make sense to those of us who have worked on projects for years and allow us to communicate with other project people more effectively. This shared lexicon is a huge positive attribute when speaking with other people who know the language, but can be a huge detriment to people who do not know the language.

Lets use an absurd example to prove this point... If someone is dying of dehydration and stumbles into a wine party, what would you, the wine snob, do? Would you start to discuss the ways in which the skins were left long into the fermentation process in order to extract all the proper tannins? Or about how the grapes were allowed to desiccate and slightly mold on the vine, just enough so that their sugar content rose and their water content fell enough to make a perfect vintage?

No, you would not do this to a dehydrated person. You would give them water. Clean, pure, clear water. Wine is not refreshment; it is taste, flavor, texture and smell. Water is life (but wine is what makes it worth living!)



So why is it that when our stakeholders come to us with massive problems in their areas, why do we expect them to speak the language of projects? Our stakeholders don’t care about a project charter or gantt chart; they care about how their business is crumbling apart in their hands.

Its not that the language and processes of project land are not important; they are vitally important and I wish that everyone shared in my belief of their importance. I do my best, when my stakeholders are on solid ground and in no danger of drowning, to educate them in the how, what and why of project theory. Most of them are appreciative for the new knowledge and can quickly assimilate the lessons into their daily activities, but that is only when their first priority is not survival.



When next a stakeholder comes to you, I challenge us all to make sure that our response to their need is not to send them off with a project document template or a complaint about how you don’t have time for them right now. Spend five minutes, acknowledge their concerns, schedule them for a half hour meeting in the next few days where you can more properly focus on their need, lending them your expertise in helping to solve their problems. Even if you do nothing more than listen to them complain for the entire time, at the end you will have built a vast amount of good will that you can call upon in the future.var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E")); try{var pageTracker = _gat._getTracker("UA-xxxxxx-x");pageTracker._trackPageview();} catch(err) {} var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));try {var pageTracker = _gat._getTracker("UA-4191072-4");pageTracker._trackPageview();} catch(err) {}

Check out this SlideShare Presentation from Jason Yip of Sydney. (Care of his blog - http://jchyip.blogspot.com)Stop Starting and Start FinishingView more presentations from Jason Yip.

In parts 1 and 2 of this series, I tossed out a few examples of current and bonus structures for BAs and PMs. Then I walked through the ways the current structures failed to drive results. Lastly, I looked at alternative options that, in my opinion, would be just as bad, if not worse, than the current methodology. Now lets turn our attention to what I think is a methodology which has the potential to drive better results.

To find out more about Dan Ariely, check out his website.

A Different Approach
We've rulled out measuring based on our customer's results and on trying to find the 'right' requirements for BAs, so what is left? If it were up to me, I'd do it in two ways, mostly depending upon how much revenue or customer satisfaction is directly attributable to your work or on how much cost you avoided by your efforts.
Let me return to m 'upsell' example from part 1, with numbers that are totally fictional for my organization. Lets say that I determine those upsells are bypassed 100,000 times per day and are only effective 50 times during any given business day. If those upsells produce $2 in extra revenue each, that's $100 per day. If I determine that each upsell takes approximately 5 extra seconds per customer call, then that's 500,000 seconds per day. Divide that up by an average 8 hour shift and you have approximately 17.36 hours at an average cost of $10/hour, making an expense of $173.60 per day. Say that of the $100 in revenue, you only make $15 in profit (before labor is removed) but have $173.60 in labor expense and those upsells start to look like a REALLY bad investment.
Not only could I actually save money by eliminating the upsells, but I save money by having a smaller code base and thus, less maintenance and documentation for developers and analysts. I'm sure there are other costs you could conceivable add in here (electricity, wear on servers, drive space, you get the idea) but the numbers make up the point.
Lets flip the scenario around and assume I figure out a way to make those upsells intelligent by looking at the customer's past order history, the items they're ordering now and the types of products other customers with the same demographic profile and then making smarter recommendations. If I up the number of upsells from 50 to 10,000, then the picture starts to look very different. Suddenly, I'm making $4,000 in profit (again before labor is removed) on $173.60 worth of employee time. When the order takers start to realize how potent of a weapon that upsell is in driving sales, they'll probably pay more attention and use it more, driving even more sales.
Still Not Perfect
Once again we're at a problem in our measurements because how do you know what is directly attributable to your performance and what is not. If you captured the requirement, but it was really the idea of a stakeholder, should you get credit for that? If the developer is the one that did the analysis to find the exact ratio between all the inputs, should all that revenue pot (or a percentage of it) be theirs?
This is where you have to factor in two more items: team and time. You really need to take a look at who was involved and their contribution to each saving or selling that made the difference. Second, you can't do one project, feature or phase, but have to measure over time. You get a slice of every addition you make and then each of those slices are averaged over a long horizon, and I'm talking years here not just a financial period.
By focusing on a team, and I don't mean that in the reporting structure definition of the word, you get lots of other side benefits like cohesion, group survivability, etc plus you remove the problem of needing precise measurements of who added what to each individual project. If someone fails to perform over time, the rest of the team will ensure that they either begin to contribute equally or that the underperformer leaves.
Measuring over time takes away the pressure of the financial cycle and puts the focus on long term health of the business. It also ensures that knowledge stays within a business and, if combined with an HR team that really understands how to recruit and retain top talent, allows for new, high-performing junior team members to gain an immediate foothold and be rewarded for their contributions.
Analysis
So, am I dreaming here? Does this make sense? Do you have a better idea? Let me know in the comments!

Dilbert has competition. Check out 1.0 FTE
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E")); try{var pageTracker = _gat._getTracker("UA-xxxxxx-x");pageTracker._trackPageview();} catch(err) {} var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));try {var pageTracker = _gat._getTracker("UA-4191072-4");pageTracker._trackPageview();} catch(err) {}

var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E")); try{var pageTracker = _gat._getTracker("UA-xxxxxx-x");pageTracker._trackPageview();} catch(err) {} var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));try {var pageTracker = _gat._getTracker("UA-4191072-4");pageTracker._trackPageview();} catch(err) {}In part 1 of this series, I took a look at how the bonus structure for Business Analysts is not very efficient in driving better results. This time we'll look at the structure for Project Managers and an alternative method for structuring their bonus plan. Part 3 will discuss what I consider to be a 'better' way to structure bonus plans for all Project People.

If you want to know more about Dan Ariely, or his new book, check out some of the interviews with him over at Big Think.

Setting a Baseline
PMs, like BAs in the last post, usually find themselves receiving bonus payments based on whatever business unit happens to pay their salary. If you're part of IT, you follow whatever bonus structure they use. If you are part of a PMO and report directly up to the COO, then you'll find yourself following that structure. Wherever you are, it is often a place where you may find yourself having trouble making a direct contribution to the company bottom line.
I've seen PMs who are BOK-WONKS (a person who spends their time studying a Body of Knowledge instead of on more socially acceptable non-work activities) complain when anyone even mentions the 'Project Triangle' in a post. Its outdated and legacy theory that has been replaced by more accurate representations, you say. Quite true I say, but one thing you can't fault the triple constraint for is providing an easy to use and easy to understand relationship between multiple, competing factors. All of you BOK-WONKS out there hold on to the pitchforks for a moment because while my example here may be less precise, I'm going for a directional position and the triple constraint does a really good job at proving the point.
You've got Time, Scope and Budget. Failing to deliver on any of the three is a potential negative to the bottom line, even if it is only failing to correctly estimate the number of deferred hours needed to complete the project. But is this your fault? You don't control the requirements, so when the BA fails to correctly specify all the needs of the business, that is not your fault. If the developer runs over schedule by months because they are a code perfectionist and the resource manager won't agree to add more people to pull the schedule back in, your recourse to keep your bonus is limited.

While PMs are responsible for 'cracking the whip', if the whip-ee refuses to budge, you are not usually their resource manager so you're left with pushing issues up to a sponsor team to resolve. You report on the schedule and on the weekly burn rate, but other than suggesting ways in which people might perform multiple tasks at once or ways to slim costs by cutting scope or hiring cheaper inputs, you generally don't have the authority to actually implement any of these resolutions.

Now What?

Lets say that your management team decides to restructure your bonus calculation and ties it directly to your ability to predict and report on changes to that triple constraint. They want to see how accurately you can forecast and divine the winds of the project landscape.

You find out that 1/3 of your bonus is tied to each of the areas of the triple constraint. The closer you are to being on budget, the more of that 33.33% is yours. The same is true for schedule and scope. The problem here is similar to the problem with a BA, how do you measure each of these areas?

Lets take time... are we talking duration or effort? Both? If you end the project on time, but blow labor by 20% because you hired a bunch of contractors at the end of the project, should you really get the full bonus percentage for the time segment of the calculation? You may have hit your dates, but your effort is way out of proportion with what your resource managers felt the project would need. Similar problems would exist for quality (I shipped it on time and on budget, but it was unusable) and budget (throwing more bodies at it).

But there is a more fundamental error with this calculation, namely that being accurate in a measurement does not necessarily translate into better results. I had a PM trainer once tell a story of how, while he was PM for a project to build a palace for a Saudi prince, they came in on time, on budget and to the exact letter of the original plan. The prince, when being given a tour of the palace, stormed out within 5 minutes, refusing to talk to anyone about the building and refusing to take ownership of the property. After months of work, the project team finally got an audience with the prince.

They explained how they completed construction on time, how they were good stewards of his money and how they fulfilled the letter of the design. The prince's reply was simple, "But you put vinyl tile in my foyer. I'm a prince, what do I care about time, budget or scope if I am ashamed to show off my palace to the other princes because it looks cheap!"

The project team measured everything exactly, but failed in the most important ways, namely to meet the needs of their customer. Tying the bonus of a PM to their ability to accurately measure a project will not work because accurate measurements does not necessarily translate into correct results.

But Wait, There's More...

Part 3 of this series will arrive very soon, so watch for it in a couple days. Until then, amuse yourself in the comments by letting us know of other ways you've had your bonus calculated as a PM!