29 June 2010

Quick update on the lack of updates

I lament some of the challenges but really, this is a very interesting & rewarding life I am living.  

Right now I have the joy of being flat out at work as one project closes and another starts, marking final assignments and (from tomorrow) exams and trying to kick off a couple of too long delayed personal/community projects. And that's just the project management part.

So stick around (i.e. make sure this blog is in your RSS reader) and I'll carry on with the agile/pm discussion soon.

In the meantime... Ted?

28 June 2010

Project Irrationality

Right now I’m reading a book entitled ‘Predictably Irrational’ by Dan Ariely. As a regular contributor to APM’s Marketplace, his opinion pieces have always intrigued me as they relate to the human side of economics. When I saw his book, I just couldn’t help but pick it up for a good read.

I purchased the book while on a business trip, killing time at a mall bookstore. It wasn’t until the next night, as I sat in an airport restaurant killing more time until my flight home, that I had the opportunity to actual begin digging in to the book.

The first chapter, about Relativity (not Einstein’s concept, but strangely enough has some parallels), proved especially interesting due to the behavior of the elderly gentleman, who we’ll call Tom, that was sitting in the seat next to me. Ariely postulated that everything in life is relative. He built his argument around a principle that people don’t know what they want until they see it in the context of their options.

Dinner and Comparative Options
As I was a few bites into my salad, Tom placed his order and it wasn’t exactly a normal one. Despite a menu that contained half a dozen rich, succulent options for grilled, ground beef, he wanted a plain hamburger. With onions. Nothing else. The waiter, Cater (this is his real name, and he did a phenomenal job of ‘catering’ to his customer's needs), was a bit taken aback and asked additional questions, hoping to better understand what ‘plain’ really meant. After a few moments of back and forth, it became clear that the man wanted just what he said. No cheese, no condiments, no lettuce; just meat, bun and onions.

The really interesting part came when they discussed the side items, of which Tom wanted none. Cater explained that the fries are ‘basically complementary with the purchase of the burger’ but he could substitute other sides if Tom didn’t want the fries. Despite a dizzying list of potential sides, Tom settled on the fries, but only after Cater first explained that the bill would not be reduced in price with Tom’s refusal of the fries.

At this point, Tom changed his mind, agreeing to the fries, but only if Cater had the kitchen make them very well done. Up to that point, Tom hadn’t even wanted sliced potatoes to touch his plate, but when seeing his options in relation to one another, seeing their relative value, he agreed to the fried tubers.

It wasn’t that Tom thought the burger by itself was a bad value as the menu clearly indicated the price of the entree. Only after Cater explained to Tom the value of the potatoes did Tom change his mind and want them.

All of that happened as I read my book and chewed my lettuce. Nothing I can think of would drive home Ariely’s point more than that dinner. But dinner selections are not the only place this theory appears. The more I pondered what I had just witnessed, the more I realized situations such as this happened to me on a daily basis.

Project Irrationality
Take, for example, a conversation I had with a stakeholder a couple of years back regarding a recently implemented system enhancement for which he had supplied the requirements I managed. The project allowed users of the software to change the methods used to pay a particular type of employee. The change didn’t result in employees being paid less but could be perceived as such if the employee didn’t understand the numbers behind their pay. Being concerned about the well being of out employees, and wanting to avoid any potential frivolous legal action, we spent a great amount of time training employees about the differences between how their pay was previously calculated versus how it would now be calculated. We went so far as to change their pay stub to show a full breakout of their pay.

It was this detail that caused such an uproar. Half of the employers who used the software thought it was a great idea to show the detail and the other half thought it only invited potential legal action, demanding we hide the detail from their employees. As my stakeholder and I discussed hiding the detail, he came upon an idea... what if we allow the employers to decide if the detail should be shown or not? We’re going to make a change to hide the detail, but since we already have the code written to show the detail, why can’t we just keep what we’ve already done, too?

From the position of my stakeholder, it wasn’t any more work for him to have it both ways, no matter what the real cost to the development team in terms of requirements management, coding, testing and maintenance. It wasn’t until he compared the value in each option, turn it off completely or allowing the employer to decide to turn it off or leave it on, that he decided he wanted it both ways.

So, what was a rational choice for my stakeholder was an irrational one for the project team. As the title of Ariely's book states, this irrationality was predictable. We, as project people, need to spend more time explaining to our stakeholders the problems inherent with decisions such as this one. While an occasional option to allow a user to make small changes is fine, when you start making allowances like this for every single decision, you find yourself with a process or application which is difficult to measure and maintain.

The next time a stakeholder decides to hedge their bets and ask for the option to do two contradicting functions in the same process, push back to the business need and see which of the multiple options really best fits the requirement. Don't be forced into irrationality because a stakeholder is unable to make a business decision.

26 June 2010

Measuring the performance of the business analyst

Doug has a post at Bridging the Gap on measuring a BA's performance.  It's recommendations are incomplete.

Measure what is important. If you measure the wrong things or only part of the picture you skew behaviors into feedback loops that continuously degrade your outcomes and make everyone frustrated.

(Only Measuring estimates versus actuals is a road to pain.)

Think about the higher level goals you are trying to achieve and measure progress towards those.

Looking for a framework? Start with the balanced scorecard as a guide.

  • Are you getting value for the work?
  • Are you continually learning and adapting to keep up with your changing environment?
  • How are your project and systems stakeholders? Do they love you or hate you? Why?
  • Are you working with the corporate processes, improving them or ignoring them? How does that affect others and overall performance?



25 June 2010

cool design tool for web apps


22 June 2010

Ignorant or Stupid?

Sometimes we get ignorant stakeholders. Not stupid, just ignorant. Many people confuse the two terms, incorrectly substituting one for the other, but they are very different terms. To illustrate, I'll turn to the dictionary:

ignorant, adj. - uneducated in general; lacking knowledge or sophistication;

stupid, adj. - lacking or marked by lack of intellectual acuity

Ignorance is a lack of knowledge that is directly related to limited exposure or experience. Stupidity is ignorance despite sufficient experience and exposure. We can work with ignorance.

Stakeholder ignorance can come in many types and flavors. Some are brand new to working on projects. Others are new to their position, or new to business in general, and don't understand their business. Its not that they don't want to help and be part of the project, its that they just don't understand what it is they have that we on the project team need.

Pre-game Scouting Report

Some time ago I had a stakeholder, who was brand new to the company I was working for but not new to the industry or his role, ask me a question about product ordering. This stakeholder was concerned about the data entry time required to process single orders with a large number of ship to addresses. The scenario was that large customers with hundreds of branch offices wanted to place a single order for replacement supplies. The replenishment would then be direct shipped to each of the customer's branch locations. Each branch would receive a very similar order, where the total amount of product shipped would be based on the sales volume of each branch.

As I dug deeper into the requirements, it became clear that the problem wasn't one that would be easy or cheap to solve programmatically. Because each location would be receiving a unique set of items, there wasn't an easy way to write a program to automatically generate a list of products and quantities and then place an order for each location. After a few minutes of discussion, I came to realize I was in for a difficult time explaining the complexity of the request to my stakeholder. I knew this would be a challenge, so I reached deep into my bag of communication tricks and went to work.

The Play by Play

I began my explanation by talking about our order entry process and what it takes to turn raw goods into a finished product. I explained how the finished product arrives at the customer's door. I explained how our customers currently placed orders and why it was so hard, given his scenario, to automate the placement of that order. The conversation went nowhere. Given his apparent lack of knowledge, he shouldn't have been a stakeholder, but as we all know, we don't get to pick our stakeholders, but they do get to pick us.

My first attempt to explain the complexity involved in his request had failed, so I decided to move away from our specific process and use a more generic example I assumed he would be familiar with to explain the concept. I used Amazon.com as an example of how an order has only one ship to address. If you want to ship to multiple addresses, you place multiple orders. Sadly, he had never shipped to anyone but himself, so the idea of purchasing something and having it shipped to someone else wasn't a concept he grasped, despite giving examples such as birthdays and holidays as why you might want to purchase something and have it shipped somewhere other than to yourself.

My stakeholder had no concept of anything that happened between him clicking Submit on the webpage and a box showing up at his front door. If he couldn't grasp how that worked with a single supplier shipping directly to a single customer, how could I explain in simple terms the significantly more complicated process he was suggesting? Method two had failed, but I wasn't yet ready to give up.

Step three was to start dazzling him with science and math. After a little digging, I found out that the average order he was describing happened for one customer per month, with a total of about 300 ship to addresses and each address would generate about $20 in sales. Over a year, that would add up to around $72,000 in additional sales. Subtract out costs of fulfilling the orders and you would probably make a profit of $4000 for the year. That doesn't sound too bad, until you consider that the company we worked for counted its sales every year in the billions of dollars.

Still, profit is profit, but we haven't discussed the costs of developing a solution to meet his needs. I explained that a project like he's suggesting, which even Amazon.com doesn't do, would probably take thousands of development hours, at an average of $100/hour for contractors, just to make the project happen. The entire yearly profit for his project would be spent hiring one person for one week. The payback just wasn't worth it. He was better off hiring a temp worker to do the data entry for him than he was trying to start a project to solve the problem.

I got blank looks. No, I'm not kidding. The math simply eluded him.

At this point, I was down to my last option. When all else fails, draw them a picture. Yes, given what I had been through already, I probably should have started with this option. I should have brought crayons. This was my first interaction with this stakeholder and most everyone else in his department would have understood the complexities without me needing to spend half an hour walking them through it.  I had made a bad assumption that he would understand as well as his colleagues, a mistake I was determined to never make with him again.

My pictures were pretty uninspired as by this point I was fairly confident he wasn't going to understand no matter what I said, did or drew. I made a few scratches on my notepad, outlining the same points I had said earlier, just with words in boxes with arrows showing how product flowed. After a few minutes of that, he still had that same blank look staring right back at me.

Post-Game Wrap-up

Frankly, I was beaten. That was the first time in many years I left a discussion without having reached the other person. I felt worn out and defeated. As I walked away, one of his coworkers, who happened to be one of the best stakeholders I have ever had the privilege to work with, pulled me aside and let me in on a little secret... I had done better with the stupid stakeholder than anyone else on their team. It didn't matter what the subject was, the guy never got the concepts people tried to explain to him.

So, at the end of the day, I had not failed, or at least had not failed any worse than anyone else. It was all at once a feeling of relief and of dread. While I knew I was far from alone in not being able to get through to this stakeholder, I also knew that his boss wanted to groom him for a more active role in their department, meaning I would be working with him more and more. Sometimes, for some people, ignorance, even stupidity, really does seem to be bliss.
At the end of the day, we really can not cure stupidity in others, but we can provide them all the necessary information for them to cure their ignorance. If we do that, then we have succeeded in our role, even if the conversation is ultimately unresolved.

17 June 2010

How I know scrum is a complete product

Scrum is more than a software development method. In fact I don’t think it’s really a software development method at all.

 It says nothing about the way you should define requirements, build a solution or manage quality or defects. All it says is pick a time period and deliver to that cycle while applying a systematic approach to intra team communication.

I know scrum works as a “get things done” approach because I have used it as a framework to help at least 2 non IT businesses achieve a set of goals.

Let me give a bastardized description of scrum that is complete, accurate and in a language that the skeptical project manager will appreciate.

  1. Start with a goal. Break down the goal into incremental steps.
  2. Discuss the steps with the team who needs to deliver the solution.
  3. Set standard time boxes. Do your best to deliver something practical and useful each time boxed iteration.
  4. The team needs to take instruction from the customer at the beginning of each iteration and report on what got ‘done’ at the end of each iteration.
  5. The team must set aside a portion of time at the beginning of each iteration to plan their work.
  6. The team needs to set aside a regular and brief portion of each day to communicate progress and problems to one another.
  7. The team needs to commit to continuous improvement and should set aside a portion of time each iteration to reflect on what went well, not well and where they can improve.
  8. The planning, review and reflection sessions, and the daily team update all need to be set at regular times to help the team achieve a sense of rhythm.


That is scrum, complete and in pragmatic terms and there is nothing software centric about that process.
And that is why most software scrum teams have also adopted quality management processes, especially XP to help get things done, and done right.

Image shared by eqqman via CC at Flickr

15 June 2010

Scrum and the PMBOK

In the first installment of this discussion I mapped my perception of what scrum delivers against the PMBOK’s Integration Management knowledge area and appended a few simple observations. Today I want to discuss why I zeroed in on integration management as the first place to look. By doing this I want to try to set a context and address some constraints to this discussion.

I went to integration management because I think that Integration (with the capital I) is the main role of the project manager in the sort of projects I work on. My projects are usually larger ones ($5M+) and I work in large organizations that rely on formal systems and structures to keep order and balance competing internal priorities.  The technical challenges are solid, and so are the organisational change issues.

Usually these projects are paid for by a sponsor who is a senior manager within the organization, or the section of the organization that the project is operating in. But the decisions on scope are often made by the middle and frontline management stakeholders. Instantly in this situation you are faced with the challenge of the people who decide what goes into the solution aren’t the ones paying for it.

It takes a certain amount of organizational maturity to overcome this problem, and often scope control and stakeholder management is always difficult. There are quite specific techniques to deal with these challenges though, and they are not in my experience embedded into the typical project approach. Instead sponsors rely upon the talents of the people on the project team to coral or otherwise align the disparate wants and desires of the stakeholders.

That’s not to say that there are not specific systems and processes that can achieve balance. One example is provided by Glen when he starts us of with the balanced scorecard as the source of our project requirements. Another is Robin Goldsmith in a Modern Analyst article from last year called BAs will falter until they discover REAL business requirements.  This is all fundamental to running a business and so maybe we are doing the customer’s work for them if we step into this space?

I suspect that if all of us looked at the projects we are working on today the majority of us would say we are working the wrong project. And the reason for that is often that projects are started for the wrong reasons, even if they are started with the best intentions.

Projects are about delivery, not about choosing goals and choosing organizational strategies. The PMBOK for example dedicates 2½ pages out of 467 pages to project initiation, and about half that space is taken up by 3 diagrams. That’s about half a percent of the total knowledge in the BOK.


Let me summarize project initiation for you; justify your project with a business case or other tool, develop a charter so everyone knows the project goals and scope, and then identify who your stakeholders are. Identify any organizational issues that are going to trip you up and go for it.

Organizations have more complete processes than this, but they are beyond the scope of the PMBOK. You may find these processes in Portfolio Management manual, product development methods and strategic planning processes. But fundamentally project selection is not the project manager’s job.

Some organizations require a 3-6 month period of maturing the thinking about a project before it really kicks off. Other places will kick a project off after a boozy lunch and a good idea.

The truth is that neither method is better than the other to any great degree, as long as you follow up the initiation process with good sense. And however it’s done; it’s usually done by someone different to the person who has to deliver the project.

When I compare scrum to PMBOK I am comparing tools that help manage the delivery of projects, not the selection of projects or setting of project goals.

Integration management includes the processes that report on progress and manage the balancing act between cost, scope (which for me implicitly includes quality) and schedule. And given that the project is defined when you turn up the unique competency the project manager brings is the ability to deliver these two things in a way that helps the project close out successfully. The other knowledge areas are useful, but not *core* to the job and not particularly Project Management specialist knowledge.

Coming up:

  • Why a Product Backlog is like a WBS which is like a PBS
  • Why procurement management and human resource management knowledge areas are not core to this discussion
  • How Scrum needs to be augmented to address Quality Management
  • And Sundry other discussions about PMBOK and Scrum.

What do you think? What do you want to hear discussed next?



14 June 2010

Processing your Requirements Document

One of my very first posts about being a BA was about how much I hate the tools BAs have to work with in our jobs. One astute commenter pointed out that most of the tools I mentioned were not really BA tools at all, but general purpose tools that BAs ended up using. This general tool approach often occurs because of a lack of funds for specialized tools or an ignorance that better tools even exist.

Given these limits on tool selection, I'd like to take a few minutes to give the BAs out there who lack specialized tools a few quick ideas on ways they can use a word processing application to be more productive in creating and managing requirements.

Use a template
Hopefully, your organization has a predefined requirements management template of some kind for you to use. If they don't I highly recommend asking if you can form a group of analysts to create a standard one for use across all projects and business areas.

Templates are great for many reasons, but the one I want to talk about speed. If you have a set template, you know the minimum amount of information you need to get to your first review. It is as simple as filling in the different sections with the appropriate material. You don't need to spend time trying to figure out what different artifacts you could or should include, as a properly created template tells you what you need. Starting with a totally blank document each time is analogous to recreating the wheel.

Say it with style
Use Styles. They're the little labels like 'Header 1', 'Header 2' and 'Normal' that are found in the toolbar, usually above the document itself. These are fantastic time savers as you can create new styles and apply them to different areas of your document for additional emphasis.

The other great thing about styles is how the Headers tie in with your Table of Contents. By correctly using a style, your table of contents builds itself for you when you tell the application to include one in your document. Creating and maintaining a table of contents by hand, especially in a very long document, can be a nightmare.

A word of caution though, especially if you're using a template. Make sure that you only create as many styles as you need. Having too many styles can make using them as unwieldy as doing multiple format updates manually. Make sure your template is stripped of all unnecessary formatting prior to its initial distribution.

Auto Text
Auto text is a feature which I find interesting, but don't personally find a lot of use for in my particular role. The idea of auto text is that if you find yourself constantly typing out a long string of terms or some unwieldy proper name, you can create a short set of keystrokes that the word processor will automatically change into the phrase. If for some reason my organization regularly has discussions about 'Very Extended Three Letter Acronym', then I could create an auto text rule so that whenever I typed 'VETLA', it would automatically be replaced by the full text.

This is especially useful if your organization has a lot of specific 'jargon' or acronyms that are unique to themselves. Consider this to be nothing more than an automated Find and Replace function. Be careful about what acronyms you set up as any time you use them they will always expand. Word processors are not smart enough to understand if you really want to use the acronym this time or if the acronym also has a common usage that does not mean the same thing as your organization specific usage.

Document Properties
One thing that I find is regularly overlooked is document properties. Any document you create on your regularly used PC probably has your name listed as the author of the document. However, if you take a document created by someone else and replace all the content with your information, the document properties will still show the person who originally created the document as the author. I've worked on projects before where the author field in document properties was a person I had never heard of and the company they worked for wasn't affiliated with my organization in any way.

There are lots of different properties in documents that could be helpful if you take a look through the list. Title, Subject, Author, Manager, Company, Category, Keywords, Comments, Hyperlink, the list goes on and on and on.

Tracking Changes
My last suggestion is the one that comes with the largest disclaimer of all my comments. Track changes can be very useful, but even more than a decade of enhancements, most word processors still do not do this very well. Track changes can do an acceptable job of showing what textual changes were made and by whom. Where the function often fails is in attempting to track changes to tables, inserted objects and textual formatting.

Even if you use the tool sparingly, it isn't used often enough in most organizations to be in the common repertoire of most knowledge workers. If you choose to show the final version including changes, you will likely need to explain to some of your reviewers how to read through the changes that have been made to the document.

If you decide to track changes, make sure that most of your internal revisions occur with the functions turned off, or that you increment the revision number and accept all changes before doing another round of reviews. This keeps the document from being overly cluttered and distracting from the actual content.

Those are my suggestions for how to get the most out of a requirements document created with a word processing application. Do you have any suggestions I didn't cover which you teach others? Let us know in the comments.

12 June 2010

A day in the life of a scrum team (Time lapsed video)

11 June 2010

Building a Better Resume

DoYouBuzz Next Generation ResumeOne of the most frustrating activities that I've ever had to do in my professional career is to make up a quality resume. Sure, anyone can lay out a listing of BA activities they have performed in a chronological format, but I feel that just doesn't do our experience justice when you look down at those printed words on a page. When I was between jobs a few years ago, I spent a frustrating afternoon looking for a new resume template to use that would show off my abilities to potential employers. I came up empty, eventually modifying a stock template from Microsoft Word. It obviously worked because 8 weeks after being laid off I was back in a new job, but the experience always left me wondering why that was the only option.

Wonder no more. If I had thought of this during those 2 months I was unemployed, I probably wouldn't have bothered getting a new job. Instead, I would have worked on creating a site that can do what DoYouBuzz.com does so easily... share your resume with the world.

There are a few things I really like about this site that other places don't do. Sure, you can use LinkedIn, Facebook or even your own website to post your work history, but this site does it all so much better. Here are a few things I really like about it:
  • Easily customize your resume layout to something that fits you and the job you're going for. As project people, we're generally thought of to be technology savvy, so a site like this, which can produce great results in a short period of time, makes us look good.
  • Embedding. I have my own website, where I spent way too much time putting together a version of my resume. Because I can embed directly from DoYouBuzz, I can update my information in a structured format and those changes automatically appear on my website, too.
  • Security. You can choose, if you want to, who can see your information and what information they can see. Not only can you keep out unwanted individuals from seeing your resume but you can choose to have all inquiries forwarded to you without the recruiter ever seeing your actual contact information.
  • Search. If you haven't searched for yourself online, you should do so often. One of the great things about a site like this is that it can actually help anyone looking for you, and recruiters will look for you, find a better quality result faster.
  • Statistics. This one really made my sit up and pay attention. I like knowing who and how often someone is looking at my information. One of the things that I found most frustrating about paper resumes is that you have no idea if anyone is even looking at them or not. DoYouBuzz provides you statistics on how many times your resume has been viewed and soon will tell you more such as where the views are coming from and how long they looked at each page.
This post might have sounded like one huge plug for a service, but I promise you its not a commercial. I found the site intriguing and hope you all find it so as well. Even though I'm not in the job market right now, I am considering moving my resume information over to DoYouBuzz so I am ready if I ever do need it quickly.

So what about you? What experiences have all of you had with electronic resumes? Does anyone have a story of something that worked well for them?

8 June 2010

Office Politics RESOLVED (You make the call)

Last week we told you about our colleague Jane's Office Politics dilemma and you told us what you would do.

What Jane did do was focus on quick wins to help her build back a level of trust. It meant compromising some of her project efforts, as some of the longer term goals would have to be reworked or simply be delivered to a lower standard than initially planned.

On the other hand she needed to do something or the project would be doomed to failure. So she took a day away from the office and reflected on her options for quick wins. Her plan was modified and she began work.

A part of this involved trying to bring her troublesome stakeholder “on the journey” but it quickly became apparent that this was not going to happen so she abandoned efforts in that direction and got focused on early delivery of business value.

The project started to pump out releases; new and streamlined business processes that started turning around work faster and with less defects (aka rework.) The benefits were tangible, but part of what was abandoned was the base-lining measurement phase of her project so the degree of benefit that was achieved was not measurable.

She restored trust with many of her project stakeholders and was commended for her professionalism under fire from the enemy, but the project only delivered part of what it had originally promised before this project manager decided to call it a day and move on.

Do you recognize any of these factors from your won experience? If you were in the person’s place what would you have done?

Picture cc from  lamont_cranston at Flickr
 


7 June 2010

Can scrum stand alone as a project management framework?

A couple of times I have made the statement that Scrum is a complete and fully integrated project management method. I’ve also said I don’t think there are any significant contradictions between scrum and the PMBOK.

I've been asked to explain myself and in a couple of upcoming posts you'll see my attempt.

To start with I mapped my opinions on how well Scrum covers the integration management processes described in the PMBOK.  This is just a first pass and I'll elaborate later.  I am very interested in your views, so help me out and add a comment below.

The first thing I want to highlight is that my view of what scrum delivers and the range of integration activities seem to more or less reconcile.  

Each sprint can be a mini project and can potentially be self contained or can be followed up by further investment.  

The first sprint in a larger project will start with some product envisioning and ramp up work.  And a sprint review can be a sufficient closure.

Lastly, this little graph says to me that the most important tool in scrum is the project backlog - thus the goal is still a customer who knows what they want.

The second thing to note is the emphasis on monitoring and controlling.  Work is monitored and measured at every step and you get early insight into problems.  There is also a strong emphasis on directing and managing the work.  These two aspects are fairly tightly lined, because scrum, like other empirical approaches value the utility of the feedback loop.

These are my first thoughts.  What do you think?  I'll add more in a couple of days.

The third half of the 'Best Practice' series



Base lining Story Points

Something I wish we had done better is base lining story points.  

Our team, and the organization we work for had always had lot's of trouble estimating.  Planning poker is the tool that has at least partly increased the teams ability to estimate the work.  Unfortunately the estimates still give me plenty of grief.  That is the estimates are regularly but inconsistently out by significant amounts.

There are many issues at play here; and many of them are typical things reported in the scrum and agile communities.  Main problems have included seeking too much information and seeking too much precision.  A third problem is a drift in the baselines.

What we did right: 
We took the first couple of dozen stories and estimated them by the Mike Cohn book.  Out of that session we took a handful of baseline stories as put them on the wall as reference markers for future estimating.

What we did wrong:
Eventually we took down the baseline stories so we could use the white board for other things.  The team lost its reference points.  

(Another important problem was that we (not everyone, but enough) forgot the purpose of estimates is to estimate, not to solve the feature design, but that's another story and one that has been well covered elsewhere.)

The lesson:
Put the baseline stories on the wall and leave them there.  Always have them in line of sight from where you do your estimates.

Thanks 2nk for this photo, CC @ Flickr

6 June 2010

Making pointless statements

How is it that so many project documents contain so few actual points?  Take this line from a business case for example;
"We aim to improve customer satisfaction."
 Sure.  Of course we do.

I can't share the rest of the business case because of confidentiality and all that, but you should understand this blanket statement is made as a basis for justifying a project and it  isn't  elaborated in any meaningful way.

What we - the project team and key stakeholders - need to know is why customer satisfaction has been put on a pedestal above other motivations.  Why is it more important than profit or sales or organisational growth?  And do we really prioritize customer satisfaction above these other things or is this project one of many and this just happens to be the customer satisfaction arrow in the quiver?

Blanket statements frustrate me.  They assume a common understanding that is almost never actually in place. When you next write a phrase like the above, do me a favor and elaborate it with context and rationales.

Picture by Brainless Angel CC @ Flickr.

4 June 2010

What is Best Practice?

In the first half of this post, we walked through the ways in which the phrase 'best practice' has been abused by different groups of people and discussed why what people refer to as 'best practice' rarely lives up to the claim. This part of the post will discuss some of the elements that must be present for a process to really be 'best'. I do recognize a bit of irony in this post because it also fails one of the tests outlined in the first half of this post, namely that there is no scientific basis for the inclusion or completeness to make itself a best practice. The difference here is that I'm up front about it being my experience and not making a claim it will work for everyone. :)

Head of the Pack

Utilization of a best practice doesn't guarantee your company or team will be at the head of the pack nor does the lack of utilization ensure you a place at the bottom. Think of a best practice as nothing more than a way to remove barriers that keep your company or team from operating at the highest of levels of effectivity.

At first glance, that might seem a crazy statement, but its really not. There are many examples in the real world of how corporations with horribly broken processes are still leaders in their industry. Think about General Motors as the poster-child for this behavior. Despite Toyota besting it in quality for decades and most all major car manufacturers besting it in cost structure, GM remained the preeminent car manufacturer for decades. They were not the best at what they did (creating brand loyalty the possible exception) yet lead the industry for a very long time.

But it was Toyota's best practices for quality and reliability that eventually led it to remove GM from its place as the market leader. Is it possible that Toyota could have defeated GM without having best practices for quality and reliability? Anything is possible, but removing these two roadblocks, along with fuel efficiency and anticipation of customer's eventual desire for smaller vehicles, meant that Toyota was poised to take advantage of any misstep on the part of GM.

What it comes down to is competitive advantage. Best practices can and do provide ways for your team or company to do what it does in the most effective manner. It not only allows you to do more with less, but more importantly, it helps you do the right things and in the right order.

We're Unique, Just Like Everyone Else

So, if best practices are so helpful, why don't we see companies in the same industry or line of business all follow the exact same process? Why do so many businesses tout themselves and their practices as unique when it comes to the value they provide to their customers?

Best practices are identifiers which set one set of companies apart from everyone else in their market. Its not that what these companies do, or even how they do it, is radically different from what is done by their competition. Usually the differences are small, but they're unique and different enough in the right ways to create a positive impact on the business. It can be as simple as saying 'Thank you for calling. I hope you have a nice day!' to customers before you hang up the phone with them or it can be as complex as adding in a multi-million dollar piece of machinery that shaves $0.0001 off every one of the 2,000,000 widgets you make every single day.

Everyone has a process, regardless of if they recognize or document it. The point of a best practice is to make sure you're doing the right things and in the right way.

A Broken Record

Best practices that really are best are ones that can be accomplished time after time with minimal oversight and correction. The more repeatable the process, the more likely it can be classified as the best. If you manage a process and find that you spend a significant portion of your time doing nothing but monitoring those who perform the process, you've either got a problem with the process or with the people not following the process. If the process doesn't work, it likely needs to be changed. If the people are not following the process, it is an indication that either the process does not contain the correct steps or that it is being willfully ignored by people who are in the wrong job role.

But repeatable is only part of the equation as the process must also be measurable. Going back to those sales guys I picked on in part one of this post, I was once told that a vendor's product included best practices for managing customers. The vendor was completely unable to explain how their product accomplished this goal. The company had no measures describing how they were the best. If no one knows where the goal line is in football, no one can score. The same principle applies to best practices as well.

A word of caution about measures is that speed is not always the end all of measures. During one project in my career, I had a major stakeholder complain that their average time per work unit spiked significantly after implementation of a new software application. They wanted to find ways to decrease their data entry time back to their historic levels. What they didn't understand was that their team's spike in time provided a significant savings in time to many other areas of the business, which decreased costs overall to the division. Their work time increased because they no longer captured only the minimum information possible, but loaded additional data that was then used repeatedly by the rest of the company. Capturing more of the customer's information early in the process was a significant change which moved the company closer to an industry best practice, but the team in questions's metrics were not inclusive enough to capture the full value of their work. They were focusing on their speed without seeing the overall process speed.

Process Gymnastics

The last aspect of best practice I'll cover is the concept of flexibility. A best practice is one that is not enshrined in stone with no ability to change in the face of market conditions or customer satisfaction. It doesn't sit in a binder on a shelf collecting dust, only brought out when someone needs to be hit in the head with it as a punishment for failing to follow it properly.

Building in flexibility usually means setting boundaries around what is acceptable and who must approve when going outside of the boundaries. There is usually a direct correlation between the degree of divergence from the norm and the rigor that must be applied to ensure that the exception is valid. The further the deviation, the higher the rank needed for approval or the more numerous are the individuals needed to approve the deviation.

One of the best examples I can provide for approval when going outside of boundaries is purchasing a new car. Sales reps know the cost structure of the dealership and know the floor price at which they can sell without getting a manager involved. They have a significant range of prices available to them, but some costs are simply non-negotiable regardless of approvals. Examples of these costs are license, tax and registration fees that must be paid to the state when the car is purchased. These are fixed prices where no amount of negotiation can result in a change in price. The customer can ask for a change in these fees, but the dealership will be legally bound to refuse the customer's request. The dealership, if it wants to make the sale badly enough, could decrease the non-fee portion of the total cost to offset the amount of the fees, resulting in the customer reaching their desired price while remaining within the boundaries of the process. Its a gymnastic stretch, but the process is designed to be flexible enough to accommodate the needs of the dealership's customers.

So what other aspects of best practice have you found in your career? Let us know in the comments.

2 June 2010

Kent Beck's new manifesto?


Team vision and discipline over individuals and interactions (or processes and tools)
Validated learning over working software (or comprehensive documentation)
Customer discovery over customer collaboration (or contract negotiation)
Initiating change over responding to change (or following a plan)

The agile manifesto has had a huge impact on the software development and project management industries.  I tend to look at these things as products (Yes, knowledge gets packages as a product all the time.)  And from my marketing days I realize that over time those who manage the product will diversify and evolve it to enter or generate new markets.  So I have been keeping my eye out for the next generation.  Lean wasn't it.  Lean is a variation on a current theme.  This new set of values does seem to stand up.  Let's see how the conversation goes.

(I discovered this via Jason Yip who found it via Eric Reis.)

Does a BA need an specialist skills?

This post at IT Business Edge reminds me of the debate about whether former shoe salespeople should be running the company or whether it's better to put an MBA in the hot seat.

In response to Ann's article David made the comment that the person in the role will lead to success or failure, and while that is true, it's also true that the scale and complexity of an organisation and it's context will drive the need for a jack of all trades versus a specialist.

Photo by Jeremy Brooks, CC @ Flickr

Office Politics (You make the call)

Recently I was discussing with a colleague an experience she had. She was hired to lead a moderate sized change project. There was to be some minor I.T. work, but the bulk of the effort was in managing organizational change.

Her first act was to identify the key stakeholders and commence work on building a collaborative working relationship. Unfortunately office politics reared its head and she ran into trouble. An operational manager who was a stakeholder, and who should have been relatively minor in the scheme of things, decided this change manager needed to be shown who was who in this zoo.

This problematic operations manager then started spreading malicious (and unfounded) rumors about the change manager’s competency and running interference on her project.

What was our change manager to do? As a consultant she felt she could not effectively rely on internal HR processes to resolve the situation. Besides, processes such as HR facilitated dispute resolution can be slow and often ineffectual in the context of projects. We operate in a turbulent environment anyway, where change is the name of the game. And lastly, HR departments are not really geared up to assist external operators like consultants who are in and out in a few months.

She turned to her sponsor, but fund that the relationship she had had with him had been damaged by the rumors. She was committed, and alone, without support.

Earlier we had discussed the options of leaving or staying and for various reasons she was committed to seeing this project through.

What should she do?

Picture cc from  lamont_cranston at Flickr