Search This Blog

30 April 2010

The costs and risks of decision making

A question came up at Ask About Projects.  "What's the difference between an operations and a project manager?"

The answer seems obvious.  An operations manager manages operations and a project manager manages projects.  This led to a few answers being posted highlighting the project manager's capacity to manage in the face of uncertainty.

I think that is an insufficient (but not wrong) answer because all managers are more or less operating in a degree of uncertainty, and it's things like process maturity and industry factors that drive uncertainty much more than the project/operations divide.

Years ago I read something (either in a textbook or journal) that talked about the frequency and impact of decisions in the context of operations and projects.  The article described how operations manages made many many small decisions about how to get things done during the course of a day.  Their focus is spread across many many things at once.  Processes, people, products and services are all being dealt with, each getting only a minute or two of thinking time and sometimes much less.  Project managers on the other hand are much more focused on a particular outcome. They spend more time considering options and assessing the likely outcomes from particular actions.

This led me to a 2x2 grid to help me think about the issue.  Here it is.  

Now, what are the risks associated with these quadrants?  

The overriding theory is that big decisions made infrequently in a dynamic industry lead you to potential doom, and that smaller lower impact decisions give you the opportunity to steer and correct as you go.  The business theorists say experiment small and often.

But there is a cost to decision making.  One cost is time and money; we have to invest our team's time and money into analysis and round up the stakeholders for consultation and formal decisions/consent.  Another is decision making rights; my boss has more than me and my subordinates have less. Of course we are all deferring to each other's specialties, but I still have the authority to tell a programmer how to do his job, even though I don't really have a clue how to program.

There are many techniques available to us for managing decision making processes on projects.  It's important to understand the details of the costs, risks and benefits before selecting your processes.  That depends on where you are working more than the type of project you are working on.

So back to the original question.  What is the difference between ops managers and project managers?  Maybe it's focus, and maybe it's the need to be able to switch between small and many decisions to important and few decisions.  Maybe this is a reflection of the need to operate in the engine room and talk to the skipper at the same time.  And even that is contextual.

Dammit.  The answer looks like another "it depends."

29 April 2010

"A free and open nature"

Are you an optimist? And do you work in an organisation where politics is rife?

Have you been assisted up by the 'honest advice' of a trusted colleague only to later realise that the information was designed to subvert your goals or team?

Why do some people actively work to sabotage projects when we are all supposed to be on the same side?  Frustrated ambition?  Jealousy? A natural tendancy to do evil? 

Interesting questions.  And I don't have the answer.  But there is an opera on the topic. (And a cartoon.)

28 April 2010

Independent peer review

We had an independent code review by Readify. It's overdue, but worthwhile.  It was a catalyst for addressing a bugbear or two.

You know those design decisions that were made early on and have always been difficult to live with?  You know you have to fix it, but you are used to it so it's not urgent.

The good news is that a most of the design decisions and the coding itself got validated.  Yes, there is always room for improvement, but we don't have a disaster on our hands.

What was interesting was the workshop going through the review feedback invested a substantial amount of time into 'professional practices.'  Topics discussed included taking personal accountability for your work, agreeing on and working to a clear definition of done, abandoning your ego and seriously reflecting and learning.

It was a classic consulting moment where the outsider comes and tells the tam exactly what it's been saying to itself, but the outsider's voice is better heard.

So; A code review.  Go get one yourself.

Here is the justification
A code review by an third party helps manage a risk for the organisation by providing independent statement of whether your team are working to a sufficient quality, and that you won't be receiving a difficult to manage application from the project team.

27 April 2010

Working with the Legal Department

If there's one word that inspires fear in the hearts of executives everywhere, its the word 'lawsuit.' If a company is in business long enough, it will almost undoubtedly end up either suing or being sued by another company or individual. It is a nearly unavoidable fact of our modern business culture that negotiations will break down and we'll then break out the lawyers.

When lawsuits happen, especially when the dispute is over process or system whose requirements are managed by a project team, its very likely that members of the project team will be called upon to answer questions about the dispute.

The first project I was ever on ended up one step away from a lawsuit; it wasn't the best way to begin a career, I can tell you that. Since that time, my career as a BA has provided me the opportunity to support different companies as they battle in the courts. While my experience in this area has not been extensive, it has been memorable and instructional. What follows is not legal advice by any means, but is the experience gained by this BA.

Remember, Legal disputes are nothing to take lightly. Matters of this type rarely go away on their own. 

Know What to Keep and What to Toss

My first piece of advice is to know your company's data retention policy and keep to that policy. This is something that many BAs I've known find difficult to do, especially if your company's policy considers documentation to have a very short shelf life. Our requirements documents often become the inputs to procedure manuals, training material and support documentation. For projects that span multiple years, it can be difficult to understand what must be kept and what is no longer necessary.

Many retention policies specify different classifications of documents. Financial records, records pertaining to legal matters, intellectual property information or long-term strategic documents are often held for much greater durations than daily operational communications.

Some companies state that all documents can or must be kept at least a certain number of days while others limit what can be kept based on what will fit in a cubicle. Policies for electronic document storage and email inboxes are often controlled by the document's age or by a size limit on a specific directory.

One rule that you can count on is that once a company has been notified that it is or soon will be under threat of legal action, any documents related to that complaint must be retained. Disposing of any document, physical or electronic, after notification of legal action is received is a nearly sure-fire way to get yourself and your company in a lot of legal trouble.

Its Not Just Documents and eMail

In a time not so far removed from today, companies facing legal action only had to worry about retaining documents, emails and maybe a database or two. Times have changed. Does your company participate in social networking? Do you have any vendors who hold information for you in their data centers? What about an offsite backup site? Do you allow txt messages on company phones? Do you have a company wiki?

If you answered 'yes' to any of those questions, then your workload for managing data retention just got more difficult. The more physical and electronic locations which house your data, the more work it is to monitor what data lives where and to be ready to retrieve the correct data in a timely manner.

Many vendors have policies that allow you to gain access to all of your data whenever you want it, but it is worth asking about access when working to negotiate a contract. 

Maintain Relationships

Your legal department, or your retained legal counsel, are your best friends during legal proceedings, but that isn't the only time you should acknowledge their existence. Ignore your counsel at your own peril.

The best way to win a legal proceeding is to never find yourself in one. If there are questions about the legality or perceived fairness of a policy, process or system, legal counsel can provide you with opinions to help guide your policy or implementation decisions. When it comes to dealing with the courts, an ounce of prevention really is worth a pound of medicine.

Constant and regular communication with the legal team during a legal matter is also crucial. You never want to have your lawyer surprised in the court room or when meeting with the opposing counsel. Attorney client privilege exists for a reason, so that you can work for the best defense without fear that private conversations can be used against you or your company.

Sometimes the requests of counsel can seem onerous, especially if they're asking for information that is either used rarely or is very old. We are all busy doing our regular tasks, so when legal asks for something that might add significantly to our workload, our natural tendency would be to push back or to deny having access to the data at all. It is our job to help legal understand the difficulties in obtaining the information and then coming to an understanding as to whether or not it is really pertinent to the case at hand. There will be times where the effort required may be greater than what it would cost simply to settle the case.

So those are my suggestions for being a good partner with the legal department. What about you? What have your experiences taught you about working well with lawyers?

23 April 2010

Trouble in Service Land RESOLVED (You Make the Call)

Our most recent You Make the Call focused on a service company in Europe that needs some help with its sales and billing processes. Check out the original post here before reading the solutions below.

The 'Short Walk' (Process Improvement)

The fastest way to lessen the possibility of theft would be to reorganize the flow of paperwork once it leaves the sales manager's hands. Instead of multiple copies being sent to two different departments, the single set of paperwork can be sent first to the AR department, who creates an invoice, and then on to the service manager who enters the contract into the service system. By changing the flow in this manner, you ensure that a customer does not receive service who has not first been billed for the contract.

The downside of this solution is two fold: first, this will slow down the process of the customer receiving service. Many service contracts are active immediately after being signed, especially if the hardware being covered is old and not currently covered by a different service vendor. By making the process serial instead of parallel, it will take longer for the contract to be active. This could cause a customer satisfaction issue, if the wait is overly long.

The second issue here is that theft is still possible, but the sales manager, AR and service manager all now have to be in on the theft. If all three are complicit and collude to steal, then this solution will fail to stop the problem. This solution may work in the short term, but eventually a dishonest group of people will find a way to steal, if they really want to do so.

The 'Moderate Walk' (Process Re-engineering)

Sales functions almost always require direct communication between the sales team and the customer. Because of the many cultural and language differences within Europe, it is usually best to have a sales team that is local to the country, if not different parts within the same country. But managing the service contract and billing functions are generally the same throughout the western part of the continent. These functions could be consolidated into a single processing and management center at the corporate headquarters.

By moving the billing and contract management functions out of the countries, the ability for collusion to occur is greatly diminished. It also can speed up the process of contract entry as it is possible that a smaller number of people would be needed to enter the same number of contracts. This efficiency would occur because the contract entry team can focus solely on that one job. If this company also has a product division, the AR services for the two divisions could possibly be combined, resulting in even greater savings for the company.

The 'Long Walk' (Systems Project)

This is the most costly and time consuming way to resolve the issue, but each of the in-country billing and service systems could be removed and a single system could be implemented at the corporate headquarters. The contract could be entered a single time in this new system, which would then create a bill that is sent to the customer. This solution is nice because the contract is only entered a single time, instead of twice with the previous scenarios, and you can then provide service and billing functions with a single user role.

As a long term solution, this can seem especially attractive, especially if you combine this solution with the process re-engineering steps from the previous solution. You could conceivably make the cost of such an undertaking look even more attractive if the system included call center and service fulfillment capabilities. A single system for all service related information could also make outsourcing of functions to a lower cost country an option as well.

So how did you do? Would you have done anything different?

Poor performers. What to do?

I have observed that there has been poor monitoring of individual performance by people and plenty of people have been able to slip schedules and deliver poor quality work with little or no consequences. With a change in labour conditions and an increase in the use of clear definitions of done we are getting more transparency in our game.

More and more people will be discovered as a poor fit.

What can we do?

The project's goal is faster, better cheaper.  But the organisation's goal is to develop it's people to maximize their potential.  (And yes Pawel, that's not every organisation's goal.)

The commonly proposed solution in project circles is to hire and fire quickly.  It's probably true that this gets you to the best result fastest.  But many larger and more bureaucratic organisations are not geared up for that.  What then?

Create or customize a job for the individual? Coach?

What do you do at the first attempt?  Where do you give up?

How much is this your problem anyway?

(By the way, if you are on my team, don't be too paranoid.  This post was inspired by a conversation from a colleague at a different company.)

Picture by {tribal} photography CC @ Flickr

20 April 2010

Journalists acting a Business Analysts

One of the activities I think a senior BA should be doing, especially if the BA works in an IT division, is routinely investigating new tools to further collaboration within the ranks of BAs and with the organization as a whole. Project and even support schedules being what they are in today's corporate world, we don't always have the kind of 'free time' we need in order to look out for new and interesting technologies that could really improve how we do our jobs.

One new service that is pioneering new methods of collaboration is Google Wave. I've written about the tool before, but a new article I saw this morning only reinforces my previous conclusion, that this is a tool that has the potential to greatly change how we work on projects. If the tool can be such a great impact as to help journalists win a Pulitzer, then surely it can help us on our projects as well.

18 April 2010

Let's not kid ourselves about how innovative we are.

From 1967...

16 April 2010

Trouble in Service Land (You Make the Call)

This is another entry in our occasional series, You Make the Call. We will present a scenario from our past BA work, with the names changed to protect the guilty, and ask you to tell us in the comments what you would have done in the situation. The resolution to the issue may contain a system change recommendation, but the solution will be primarily concerned with the underlying business process.

The Setup

You are a BA for a multi-national service company operating in Europe. You are headquartered in France, but have local offices in most countries in western Europe. Your company is in the business of selling service contracts for computer equipment. Each country has its own sales and service team, along with its own internal systems for financials, billing and service tracking. Your company has grown its service arm organically over the years and thus none of the in country systems are integrated. Each country has a sales manager who focuses on bringing in revenue as service contracts and a service manager who controls the fulfillment of the contract through call centers and field technicians.

When a new service contract is signed in a country, the sales manager forwards a copy of the contract to the service manager, who enters the contract in the service system and a copy to the AR department who bills the customer. If the customer fails to pay their bill, the AR department contacts the sales manager who collaborates with the service manager to stop all service of the customer's account until the bill is paid.

All countries, save one, have a very similar revenue to cost ratio. After an internal audit, it was discovered that the sales manager for this one country had been receiving off the books payments from customers for service contacts that were never billed through AR, but which were serviced by the service team.

The Question

The sales manager was dismissed from the company, but the executive team is now wondering if the same behavior is happening on a smaller scale in all of the countries. The audit team is currently undertaking a company-wide review of all contracts to ensure they were paid for by the customer.

You, as a senior BA, have been called in to assist in designing a new billing and service execution process. What changes do you make to the current process to ensure that all contracts sold are properly accounted for by both the service and the AR teams?

14 April 2010

Product Demos for Dummies

Something I've been doing a lot of recently is giving product demos for a new packaged software application my company is considering for purchase. Because I was the lead in requirements elicitation for the project, I was kept on to manage the requirements for the implementation phase as well. Because the gap process required someone who knew the requirements inside and out to participate, I spent a lot of time learning the potential software applications as well. Once a vendor was tentatively selected, I ended up being the logical person to demo the solution to the user community.

What I didn't realize at the time is that I would end up giving the exact same 5 minute demo dozens of times over the course of several days. I've done this same demo so many times now that I'm better at doing it than are the employees of the vendor!

I've given demos for all kinds of software packages over the years, so I've had a lot of practice finding ways to give an interesting and informative demo to people with a limited amount of time to listen. Too many people have presented a bad demo by not giving me the right type or amount of information. Seeing so many bad demos has made me very conscious of not making the same mistakes I see from others. What follows are my 'rules,' gleaned from sitting through many bad demos, for giving a great demo.

Do Your Homework

Before you show up to give the demo, understand the audience who will be in attendance. If you've got a mostly technical crowd, don't waste half your demo time on a company overview. If you've got executives, don't dip into technical details that differentiate your platform from the 400 other vendors in your market segment. If you've got a mixed audience, try to bring something for both, but not so much of either that you lose everyone.

It is tempting to show off the whiz/bang functions of the application, especially the ones that make the audience oooh and aaaaah like they're watching a July 4th fireworks display. Include these items only if they can directly build the case that the application you are demoing can directly improve the lives of the audience. Don't waste time showing items that are irrelevant to the subject at hand, no matter how cool they might look.

Consider making a short list of 'anchor points' for your demos. These are items that you know will be of extreme interest to the audience and must be included for the demo to be a success. Having a list of these items will help you to focus on what is important when you start to write your demo.

Script It then Rehearse It

Once you know what you're going to say, you need to know how you are going to say it. The best thing you can do, especially if you're new to giving demos, is to write out the demo. I'm not suggesting you outline it, although you might start here, but write it out word for word how you plan to say it. User your 'anchor points' as a starting point. Place the points in logical order and then add in the appropriate and necessary details for each point.

Once the demo is written, practice saying it out loud. Talk through the entire demo without the system in front of you. You'll quickly realize that while some things make a lot of sense when written out make no sense when you have to say the words. Time your demo and see how long it is in comparison to the time you'll have to present it, then adjust the text accordingly.

When you know you're comfortable with the words, add in the demo system. Walk through the demo at least half a dozen time from start to finish with no breaks in the flow. Ensure that your demo environment is configured correctly and matches the flow of your speech. Don't get caught trying to demo something that doesn't actually work. You'll lose creditability with your audience by spending precious minutes trying to figure out why that really cool thing just won't isn't working right.

The last step in preparation is to give the demo to your peers. Grab some coworkers and pull them into the room with you. Ask them to write down the areas you did well and the areas that need some additional polish. Take their feedback and incorporate those changes into your demo. Make sure that the audience includes both people who are familiar with the system and processes you're covering along with people who have little to no idea what you're talking about. You need multiple viewpoints to be able to accurately assess if your presentation will be understood by all in attendance.

Lights, Camera... Action!

You've researched, you've written, you've practiced and now the doors are about to open, releasing a flood of stakeholders into your midst. It is now prime time and all eyes are on you. Don't make them cut to a commercial early just to get you off the stage!

Remember that this is your demo; you own it and are responsible for it. Cover the content you need to cover and don't get distracted into politics or let someone bully you out of the way. Stand-up comics don't let audience members take over their show and neither should you. Make sure you know how and when to correctly interrupt someone asking a question and how to draw out a question from a person who is having trouble articulating their thoughts.

Even the best moderators will occasionally still be derailed from their script. If the subject brought up is pertinent to the demo and you are prepared to speak to it, then by all means, do so. You're there to meet the needs of the audience, so answering questions they all have is usually a good idea, provided you answer in a way that doesn't simultaneously torpedo your presentation.

Its always nice to have a few 'extras' items you can show off if no one asks questions and the scheduled demo ends early. Because these 'extras' are not part of the official demo, you don't lose anything by leaving them out of the script.

My last suggestion is to always leave a little time for questions at the end. If no one has any questions, you can always dip into your 'extras', you can release the crowd or you can even ask them to come up and test drive the application themselves. The last option works especially well if you have a good ratio of systems to people, the closer to even the better.

What about you? What suggestions do you demo pros out there have for the rest of us?
Image courtesy of

12 April 2010

A project manager's job is integration

So why do so many projects separate what should be integrated functions?

An obvious example; separating the ownership of scope from the schedule and budget.  A project sponsor cares about schedule and budget and then delegates the articulation of requirements to managers and operators who are not directly aligned to the sponsor's goals.

Is this "Dis-integration?"

Cultural paradigms and project teams

I forgot to mention, I wrote a post for Bas at Project Shrink late last year.  In case you want to take a look, it is here.

It is about how organisational culture affects they way you do business, and if you are on the journey to an improved organisation there are some things you need to be aware of.

Check it out here.

8 April 2010

Dunning–Kruger effect

The trouble with the world is that the stupid are cocksure and the intelligent are full of doubt.
— Bertrand Russell

Verified by Dunning and Kruger.

The space between gut feel and mechanical analysis

"My point was not the Gladwellian idea that rigorous and painstaking methods should give way to gut feelings or intuitive “blinks”. Rather, it was the certain kinds of rigorous and painstaking methods should not be applied by force in situations where qualitative deliberation is more appropriate."

Tim Van Gelder is a Melbourne blogger (among other things) that I have been following for a while.  His comments above come from a recent post that leads n to a discussion about why simplistic application of analysis tools result is poor results.

Think about the "Three Options" joke that goes on in consulting gigs and project proposal phases.  There is usually one clear and simple approach sandwiched between two obvious no starters.  Why do we waste our time?  Is there a better way?

7 April 2010

The BA and their Phone

This picture, taken on my wedding day, says a lot about me. Yes, I am addicted to my iPhone. No, I don't see that as a problem. In fact, I think that my obsession is actually a very good thing, especially when it relates to my job.

So, how does an iPhone translate into making someone a better business analyst, you ask? I'm so glad you asked because there are so many answers to this question!

(Note that while this article is iPhone focused because that is the device I own, any sufficiently advanced mobile phone such as a BlackBerry, Android or WebOS device should allow you to do most of the same tasks.)

Planning Functions

These are the 'no brainer' ways in which an iPhone can help you be a better analyst. You've got your email, phone and a calendar right inside your pocket. True, a BlackBerry can do these things equally as well (some would say better, but that is a matter of opinion), but these are just the basics that you need.

Beyond the basics, you've got a lot more options. The iTunes App store has a whole list of Getting Things Done applications available for free and for purchase. Some of these apps will allow you to sync your to-do lists with your computer and even view your lists in a web browser. Never again will you forget an action item or task (provided you remember to open the app of course!) If you're cheap like me, you can even use the built-in Notes application to jot down a reminder for later.

Do you travel a lot as an analyst? The Google Maps application is great for helping you find that one building that is located in rural Nowhere, Kentucky, but travel doesn't end with mapping! There are applications which can take your email confirmation from major travel websites, break it out and provide you with an itinerary for every step you take. There are applications which will help you find a good restaurant where you can take a stakeholder out for lunch.

Requirements Elicitation

The built-in Voice Memos application gives you an easy way to record requirements as stated by your stakeholders. The built-in microphone isn't the greatest, but having the recorded memos sync'd back to your computer for easy review and transcription is incredibly helpful. If the controls on Voice Memos do not meet your needs, there are numerous more powerful applications that exist in the App Store that will likely meet your needs.

What happens when you're in a discussion with a group of stakeholders and two of them can not agree on a particular fact? If you have an iPhone, the answer is easy... look it up! There are lots of search applications out there for use from Google, Wikipedia and others. If you don't want an app, you can always use Mobile Safari and search through it. Never before has it been easier to quickly find information relevant to you than it is today.

What if your stakeholders are having a tough time understanding a concept you are attempting to relate to them, or they would like to see a visual of some process or system you are describing to them. There are many apps that use your touchscreen as a drawing pad, allowing you to show the stakeholder exactly what your idea is if you don't have a whiteboard or pencil handy. This works especially well during those conversations where you're in an elevator with someone for a minute or two and they ask you a 'quick question'.

One thing I've started to do in recent months is using a service called Dropbox. The application installs on your computer and allows you to securely store files in an online fileshare. You can then give other people access to view or update specific files and folders stored in the cloud. This company also has an iPhone app. As I moved to different PCs, I found it easy to keep all my documents stored in my Dropbox. If I went to a meeting without my laptop, I still had my iPhone to use in case I needed to refer back to any documentation.

Professional Development

For those of us who are IIBA or PMI members have access to PDF versions of our respective Body of Knowledge documents (BABOK and PMBOK). We can place these files in our Dropbox and then review them whenever we have a minute of free time or if we find ourselves in need of a specific answer for a specific situation.

The Kindle app, and the new iBooks app from Apple, will allow anyone to download books to their device. This is a great thing for those of us who have a long commute or are frequent fliers.

We can not discount how simply using an advanced device such as an iPhone enhances our thinking about technology and process. Think about what we had to do to perform a Google search on our phones before the iPhone came along and compare that with how easy of a process it is now. By simply using one of these devices on a regular basis, we are keeping our skills and knowledge up to date.

By being so knowledgeable about our new phone, our stakeholders are also more likely to look on us as progressive individuals who embrace and can articulate the ways in which technology can enhance our lives. This can be a credibility boost to us in general when our stakeholders see that we understand the impact technology has in a general way and that we can apply that understanding to our stakeholder's specific situations.

So those are my ways about how having an iPhone can improve a BA. What about you? Are there ways I did not mention that you have found to use mobile technology in your work life?

1 April 2010

Role assignment to teams

One of the secrets to success for many successful project managers is a tight breakdown of roles and responsibilities.

(If you aren't familiar with the Role Assignment Matrix (which is probably a clearer and less ambiguous technique than a RASCI) you can read more about it here and here.)

So, what's up for a scrum team?  How do you assign responsibilities to a group of people?  By making everyone responsible aren't we making no-one responsible?  Isn't this the underlying problem behind the tragedy of the commons?

Well, no actually.  Because people are part of a community.  And groups can be accountable.

What does matter is the size of the group and the culture that links them.  Small groups are better able to build a strong culture.  People talk about groups of 5-9 as optimal sizes for working together on common tasks. After that size the communication overhead breaks down.  And so does the group identity. All of a sudden there are two groups, and divergences in culture start to emerge as people identify with one group over another.


Small teams can be accountable for outcomes.  And of the culture is supportive, large groups can work well together also.  Use judgement to size a team.  See if there are groups or factions emerging and think about breaking it into multiple teams.

Picture by Cirne, cc @ Flickr.