Linking Value Stream Maps to the 7 Wastes

I am going to show you how to improve on the value stream mapping technique by combining it with the 7 wastes. Both of these are part of Lean thinking and this post assumes you have a basic knowledge of both. Here is a simple overview of them:

• Value stream mapping is a visual way of showing your processes from start to finish. Draw boxes for activities and lines between them for the delays in between. You can then note down how long each activity and delay takes. This helps to highlight where delay is costing you a lot, rather than the usual assumption that you should simply improve process steps.
• The 7 wastes come from Mary and Tom Poppendieck’s translation of lean manufacturing wastes to those relevant to software development (see their book Lean Software Development)

The 7 wastes are as follows:

1. Partially done work

2. Extra processes & re-learning are the same

3. Extra features

4. Motion

5. Waiting

6. Task switching

7. Defects

Now let’s get clever and link these together! Step one is to create the value stream map. Step two is to review it for waste. This is shown below with the value stream in white, delay times in yellow and the wastes in blue…

After creating the value stream map you can now identifying waste by asking these questions (as a starting point):

1. Partially done work
- Does the process sometime get partially done because you are impeded?
- Are you clear on what “done” is?
2. Extra processes
– Is the process necessary at all?
- Is you process passing information in the most optimal way?
3. Extra features
– Is the process producing anything that is unnecessary? e.g. a sign off doc
- Are you building features for the future rather than for now?
4. Motion
- Can you avoid a handoff of information?
– Can one or more processes be done by the same person or as a group?
- If you have to handoff information can you improve the way it is done?
5. Waiting
– Is someone waiting around for something to be done rather than chasing it down or helping?
- Can you improve your information notification system?
- Overall how long is it before the customer sees value?
6. Task switching
– Are people task switching because of a bottleneck, rather than solving the issue?
- Are people task switching because they’re working on too many things at once (WIP)?
7. Defects
– Is the root cause of the defect one of the factors above?
- Can processes be improved to proactively stop the defect?
- Is the defect caused or more likely to happen again because of a delay?

Happiness as a metric

I have recently come across happiness being recommended as a metric by Jeff Sutherland and being worked on by a company called Crisp. The view is that this can help an organisation improve. Rather than take this as a good thing to do on face value I thought I’d do some reading.  This post is largely considers the psychology of happiness based on the work of Jonathan W. Schooler, Dan Aiely, and Georget Loewenstein, with a reference to a New York Times article. I strongly advise you read this work if you want an in depth guide, as they provide evidence in the form of experiments. The recommendations and conclusion sections are my own which draw on those resources.

Happiness Overview:

• Jeff Sutherland has stated that concentrating on happiness lead to a 500% velocity increase over a year in his company
• A NY Times study showed happiness was attributed to making progress in meaningful work   - Assisted by managers removing obstacles, providing help and acknowledging strong effort

Happiness is Affected by Context:

• Strack, Martin, and Stepper showed that people search for context when asked about happiness
• Any external contextual clues can affect the rating
• General happiness ratings can be affected by situational factors such as the current weather (Schwarz and Clore)
• Recommendation: Apply specific context to the happiness question(s)

Frequency of Happiness Measurements

• Ariely and Zauberman showed that frequent measurement of happiness muffles the overall real experience by overwriting the subtleties of our real experiences
• Recommendation: Measure happiness infrequently

Happiness Measurements and Self Reflection

• Wilson and Lindsey showed that increased self reflection has a negative affect on our ability to judge happiness
• Discouraging self reflection and taking fast snapshot opinions produces more accurate and repeatable results
• A common finding is that greater awareness actually leads to a more disappointing assessment of happiness
• Recommendation: Have very fast reflections on happiness (i.e. sub 3 second answers)

Knowing When You Are Happy

• Great caution must be applied to the assumption that assessing moment to moment hedonic (our internal) experience reflects the persons underlying experience
• Csikszentmihalyi concludes that it is not possible to continually consciously monitor how we feel throughout the day
• Due to this lack of awareness it should not be assumed that our appraisals of happiness will match how we actually felt throughout the day
• Recommendation: Be aware that the results of monitoring happiness may not be accurate

Happiness as a Goal

• Schooler et al did a study which measured the effects of happiness which showed: 1) Trying to be happy can lead to lower happiness 2) As also concluded earlier, personal monitoring of happiness can undermine the ability to gain happiness
• Recommendation: Happiness should not be set as a goal but simply monitored

Summary and Conclusions

• Measuring happiness can affect happiness in a negative way, to minimise this effect measurements should be:

– infrequent

– have specific context to the question

– be done quickly

• If we are looking to improve via root cause we will need people to think about “why”:

–  This measure may therefore be self-defeating

• If we need root cause why not ask a more context specific question, in this example Christiaan Verwijs targets team morale rather than happiness:

http://www.christiaanverwijs.nl/post/2012/07/24/Agile-Teams-Dont-use-happiness-metrics-measure-Team-Morale.aspx

Agile Impediments – Hints and tips

Here’s a potential problem:

An impediments is raised in a retrospective, we do root cause analysis and discover we can’t fix it, however the item is still chosen as one of our “actions”. Now the action ends up being to give the problem to someone else to solve. That person doesn’t really want to solve your problem and ignores you, this goes round and round in circles with you raising the same impediment and trying to find an owner. Your team ends up demoralised and state that the retrospectives are a waste of time and no one cares about them.

There is a better way!

Track your impediments as hours lost against each story, ensure that all teams are doing the same. Identify common root causes (you could set a category). The hours across the teams will build and build, this kind of information is difficult to ignore. Compare the two approaches:

1) We want you to solve our impediment that came up in our retrospective

2) We want you to solve our impediment which is costing each team 20 hours per week of wasted effort

You have automatically written the “justification” part of a business case, people understand this is a priority. This also helps with seeing the wood from the trees when you have a lot of problems. Finally this frees up your retrospectives to work on actionable items.

The Agile Manifesto – Working software over comprehensive documentation

• Have you ever made the assumption that passing information by documentation was the best way to do it?
• Have you ever made the assumption that someone has read and understood the information in full?

The above summarises two of the problems with information passing. Comprehensive documentation can of course be improved with diagrams and structure, this is a good reason for the creation of UML. It is still reliant on the person receiving it understanding those techniques and reading it in full.

• Did you assume you’d made no mistakes in the documentation?

Even if we passed the information perfectly this doesn’t solve the problem of us making mistakes or omissions. How many defects do you find in your software? I doubt it’s zero! Now how many defects are in your specifications? How often do we assume they’re perfect?

A blind allegiance to documentation was the cause of many mistakes with waterfall off-shoring. We made companies sign up to contracts to build software based on documentation we provided then assumed it’d work!

• Agile uses stories and story point estimation to help solve this problem:

A story is starting point for a conversation, it helps drive out the detail, done properly it never assumes we know what it is. That is why the story doesn’t have all sorts of UML diagrams attached to it as standard. All those other diagrams can supplement the story as required.

The story point estimation is done as a team, all members of the team (playing planning poker for example) estimate on what they understand. If the sizes are not agreed the team members ask questions until they understand enough to agree them. If you don’t understand the detail don’t blindly agree!!

Finally the acceptance tests can then be put in place to clarify what the story means in business terms. This often uses the Given, When, Then format.

Balanced KPI’s – Watch out!

“What you measure will affect behavior” – the Hawthorn affect

Consider this carefully when setting out KPI’s. How can I stop my KPI’s driving poor behaviour? I’m sure you’ve seen the three factors below:

• Time – I want it faster
• Cost – I want it cheaper
• Quality – I want higher quality

It’s very common to say I want it faster! but do you want the result of that which could be higher cost or lower quality. I hope you can quickly see where this is going.  Let’s apply this to some chosen Agile KPI’s:

• Time – story cycle time
• Cost – function point analysis (shows how much work is being done by a team or department)
• Quality – software complexity rating

Now if we don’t have a KPI for each of these we can unbalance our department!

The Agile Manifesto – Individuals and interactions over processes and tools

Here we have the agile manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Let’s look at the first one…. individuals and interactions over processes and tools

Often processes are put in place so that command and control structures can measure and control what is happening. For example they may have been put in place to control a high risk situation or to fix an actual problem that occurred. There are pitfalls in processes that you should be aware of:

• 1) Doing process activities that add no value.  Firstly my post on valuable activities (please read) highlights possible waste, your process may be insisting on activities that are not always valuable:

http://everydayagile.wordpress.com/2013/01/12/valuable-versus-value-your-customers-needs/

• 2) Poor information passing due to rigid process. Next consider tacit information, this is information that is it your head but difficult to pass along. This is linked to one of the seven wastes called motion (in manufacturing it’s called transport). Knowledge degrades as it is passed on. Your process may be insisting on outputs of a particular nature, such as a certain type of diagram to follow the process. This can ignore tacit information, people learn in different ways and people have different skills (and techniques) in passing information. A conversation can minimise the risk of poor information passing in a way that emailing a set diagram every time  never could.
• 3) Tracking using tools to give confidence that something is working even when it isn’t. I could look at a process and say that it is successful if it is followed. To see if it’s followed I use a tool. Let’s consider TDD, I track unit tests numbers and I see lots of unit tests so I assume it’s working. What if those unit tests are poorly written? Wouldn’t it be better to have a conversation to discuss with experts as there is a lot more complexity which cannot be determined by a measure. Note: there is no problem with measurements but be careful to understand what they do and don’t give you.
• 4) Choosing your tool to purely measure but not collaborate. What if I chose a tool that measured code quality over a tool that helped improve code quality?
• 5) Your process gets in the way of collaboration. If I insist on a specific way of doing something it may be hindering collaboration. For example, someone wants to work with you to drive out a solution, but the “process” is for them to provide the solution then pass it to you for review.

 

Valuable versus value – your customer’s needs

There is a subtle different between these two concepts.

A valuable activity may be a design document, a user story, or even a conversation. Value is what the customer is after and that’s working software (or products). Everything else is waste!

Let’s look back to the waterfall days, we spent a lot of time making sure we did design docs whilst filling in the required diagrams, screen shots, then signing these off. The quality of the document was paramount, we hardly ever asked if it was valuable!

• Lean principles run on “just enough, just in time”. This is key, the “just enough” part is focusing in on the valuable activity

• A core agile principle is “working software over comprehensive documentation”, again you can see the focus on valuable activities

So you can now see the hidden meaning in why these principles exist. ALWAYS question if your activities are valuable. Understand that at the end of the day value is what you’re really after.

When you review your processes consider these questions:

• are you passing the right information around to help you build your software?
• are you slowing down the passing of important information?
• is the way you pass that information optimised? think email, presentation, document etc.

You could draw a value stream map to see each of your process steps then ask the questions above on each one…

Improving your retrospective actions – A3 thinking style

Let’s improve the usefulness of the Agile retrospective…

OK so you’ve done your retrospective and highlighted your main issues. You have some sort of loose tracking on them, you may put them up on your Agile board and chat about them in your stand up or each retro. Does this always mean something gets done? The retrospective should not be a tick in the box activity or it has no value.

So how do I ensure my activities are done and can we add some structure?

1) I could add a story, story point it and add it to the release but do I really understand how to solve the problem?

2) or  the team can work on an A3 problem solving document, understand the problem, how to measure it and progress it. This is a structured way of working.

The A3 actions can then be taken into your sprint planning!

Here’s another post on how to do A3′s:

http://everydayagile.wordpress.com/2012/04/08/a3-thinking-the-problem-before-the-tool/

Stories – What are they for?

What’s the point of a story? a strange question but worth considering in more detail. Like big design up front we can slip into poor behaviour around our agile artefacts. The primary goal of a story is to enable communication between you and your customer to ensure the right thing is delivered by driving out uncertainty.

You could spend a lot of time stating the obvious and considering every scenario. If you’re coding using a BDD tool, trust your developer to work on obvious scenarios without specifying them all up front. The advantage of tools like SpecFlow is self documenting code with scenarios in a “Given ->; When ->; Then” format which can then be checked later.

Usually your initial story and acc criteria are stored in a place that is not linked to code and are discarded after the story is done. Think about driving out uncertainty to build the right thing as you work that is the true value of a story.

Key Performance Indicators (KPI) – The basics

What is a KPI? In simple terms it’s what is key for your organisation to work on to be successful. This contrasts with a Performance Indicator (PI) that is something useful to measure.

What makes it key? Think about the things you can measure and consider this example. You look at story cycle time in your Scrum, it takes 19 days to complete a story but your Scrum is 10 days long. You decide you want to release working software every two weeks to live. Oh dear! Your stories are late and run into your next sprint. Let’s make the story cycle time a KPI.

I could measure and improve all manor of things to help succeed at this KPI, what if the story cycle time was affected by code quality which caused defects, poor acceptance criteria, infrequent software deployment etc. etc. Improving these items may help you to improve. Chose your KPI’s carefully and limit to under 10. Too many and it’ll be hard to see what matters.

Scrum – Raise those impediments

Recording impediments is a great way of highlighting problems and their cost across multiple Scrum teams. If you track them you can see how long they take to close and how many there are to help discern their real impact. Without this visibility some will end up in a release retrospective as minor issues and are often unquantified.

A regular small delay may not be a teams highest priority but what if it affected everyone and regularly? The real cost may be far higher.

Are you utilising your offshore vendor?

Every vendor I’ve dealt with will go over their size and capabilities when pitching for work. Most claim to be at the forefront of technology and process. Then you onboard a team for general work and they follow your processes, or occasionally pitch for new sales.

If your company lacks technology or process maturity shouldn’t they be looking to help? It’s not just new work they should be pitching for. How would they improve development or test given the choice, what frameworks and process can help everyone? Ask your vendor what they can do for you!

The User Story – Did you capture all your stakeholder requirements?

So you have a lot of user stories in the usual format (two variations on the theme below):

• As a user <who I am> I want <my requirement> so that <benefit>
• As a user <who I am> I want to do <action> in order to <goal>

Now you may jump to the conclusion that your customer is always the user but is that always true? What if we have an Application Support Manager in the organisation who needs some functionality along the lines of this story:

• As an Application Support Manager I want a report showing how often the system goes down so that I can analyse the results and ensure we meet a service level of 10 minutes downtime per month

This is all very well but now we have a problem. How is the product owner going to see any business value in this? To top things off it’s very unlikely that they would come up with this story in the first place! So get your stakeholders involved in writing the stories with the product owner as well:

• As a stakeholder <who I am> I want <my requirement> so that <benefit>

To ensure that this work actually gets done you can include the stakeholders in the sprint planning or product backlog grooming where they can negotiate the value with the product owner. You can also use your Minimum Marketable Featureset (MMF) to highlight those stakeholder stories that MUST go live for a release to be successful.

Project Portfolio Management – Prioritise your vision

So you have vision statements for each of your projects and you’re now ready to set up a portfolio management group. Start by seeing your portfolio of projects as a prioritised list. The value of these projects can be grouped by understanding what’s important to your company (I’ll cover corporate strategy in later posts).

Agile development techniques give you rapid feedback and deliver usable functionality early on in your projects. You should be providing business value each sprint so you can revise your expectations early. This is much better than waiting until the end of the project to see if it succeeds. This can now drive better decision making for the portfolio manager and relevant stakeholders.

So let’s look at some real scenarios for a project on your portfolio. You are designing a web site for your company. Your idea is to sell products that you have in your shop. On your portfolio you start with a project to allow people to view the products but not sell.

Project vision statement:

I want our customers to be able to see the products we sell on a public web site with our contact details, so that we can increase interest and get them to come to the store, unlike now where they have to find us in magazines, allowing us to get people into our shop rather than going to company XYZ’s.

Ok so that’s clear enough to start with. So let’s decide on a few simple KPI’s (I’m ignoring ROI for now):

1)       Number of hits on the web site

• Expected: 10 per day

2)      Revenue figures

• Expected: Increase of 10 products sales per week

Scenario 1: Accelerate

The project delivers a web site within two sprints and goes live. This release contains our garden range and contact details for the shop. Let’s check this against our expected KPI’s:

1)       Number of hits on the web site

• Expected: 10 per day
• Actual: 100 per day

2)      Number of hits on the web site

• Expected: Increase of 10 products sales per week
• Actual: Increase of 30 products sales per week

The amount of sales being generated has increased significantly from our expectations and our ROI has shot up. These figures how caused the project to overtake others in terms of project priority so we decide to put more resources on to it and put more functionality into the delivery.

Scenario 2: Shelved

Another project has turned out to be much higher value than expected so this one is now being shelved so that resources can be diverted on to it. The project can be re-prioritised onto the portfolio backlog.

Scenario 3: Halted

The project is started off well and returned really good figures for the gardening section, since adding the books and paint content we’ve seen no increase in hits or sales. The project is halted. Please note that it has returned some business value.

Scenario 4: Abandoned

Following one sprint and putting the gardening furniture online we check the KPI’s, turns out these are well below expectations. As a company we pull the plug early and abandon the project.

1)       Number of hits on the web site

• Expected: 10 per day
• Actual: 1 per day

2)      Number of hits on the web site

• Expected: Increase of 10 products sales per week
• Actual: Increase of 0 products sales per week

Further reading:

This article has been of great use to me in this post, so if you want more detailed information please take a look:

http://www.scrumalliance.org/articles/58-managing-an-agile-project-portfolio

Getting the best out of your testers

The role of the tester usually goes along the lines of:

You write the code, and then I test it.

What’s wrong with that statement? Essentially you’re missing a great deal of the skillset that a tester has. A tester will often look to break a system when doing exploratory testing, searching out scenarios and using their experience to point out where functionality, security or performance is poor. There’s great value in this up front! The acceptance criteria, or amending the definition of done, if it applies to all stories, is an area where the tester can add a lot of value. The product owner may know their product really well but the tester often knows the system in greater detail. So make sure your testers are involved in writing the acceptance criteria and actively helping the product owner out. Don’t forget your NFR’s too.

What’s My Project’s Vision? – The vision statement explained

Imagine you are a senior business stakeholder and you’ve decided to change the way that insurance claims to knees are done. So you write a high level project description:

Project Alpha – To stop paying out as much on knee surgery

With that description it’d be hard to peak people’s interest or even worse if you weren’t there, how are people going to understand that value of it, or even what it is? So let’s look at a vision statement to tighten up this process. I’ll use Moore (1991) as the foundation for this. The component parts are:

1) Who is it for?

2) What needs will this fulfil (ideally your customer’s needs)?

3) What is the key functionality?

4) What are the key benefits?

5) What current competitor or current practice are we comparing this to?

6) In what way will our product be different?

Let’s do an example on our knee surgery project with the numbers mapped into the sentence we’re creating:

1) Our customers requiring knee surgery 2) are unnecessarily going for knee operations when they have twisted knees 3) so we need our main system to flag these for review rather than authorising them 4) so that they can avoid discomfort and we can save unnecessary costs 5) unlike company XYZ 6) we will ensure a full doctors review first.

So there you have it, a bit more descriptive than the original project title isn’t it! Now that it’s much clearer, when you ask your team to break down the stories and put some detail around what they need to do, this should focus them. You can then apply ROI to the project with the vision in mind.

Now don’t think this is limited to a business project. You can move the vision into many aspects of your business, let’s look at a few examples, I’ll keep the numbering so it’s clear what we’re doing:

1) Our staff 2) are often coming in ill and spreading their germs around 3) so we need to educate them about not coming in when feeling bad 4) so that they can avoid spreading their germs 5) unlike the current sickness process where we meet them first to check their health 6) their line manager will ensure they phone in first.

1) The support team 2) are not clearing their defects within SLA 3) so we need to set up a reporting system that flags when they have one day left 4) so that we can make sure these are prioritised 4) so that we can pick these up with sufficient time 5) unlike the current reporting mechanism that waits until they are late 6) we will ensure that the application services manager monitors these daily.

Studying for Success

Solutions can be hard to create when you’re drawing on limited experience. How do you know what you’re doing is the right thing?

I’ve sat in numerous meetings where the solutions that have been proposed that are out of date, or in some cases just plain wrong. This represents a real commercial issue for a company, you could pull in the wrong direction for a long time before you realise. I’ve even seen people making an entire framework before a specialist has walked in and said, “our programming language does that out of the box!”.

There’s a lot to know out there so try to have some understanding of where your product and processes can go. If you have a project coming up that could benefit from a new solution then here a few tips for studying:

1) Put specific time aside for targeted study, it can often help if your team is doing this together. Many companies magically expect their staff to be experienced and with so much to learn in the computing industry this can help focus their efforts.

2) Decide how you want to share the information, do you want everyone to benefit? I really like wiki pages for this with links, although you could go as far as a team blog!

3) Start by looking for blogs, books on the subject, videos and articles on respected web sites. Now draw up a skeleton of what you want to study, sometimes a mind map will help in this (see XMind for a great free one) or you could write this like the contents page of a presentation

4) If it’s a process you’re working on then look for real world example of it in practice and learn from other people’s mistakes!

5) Identify specialist forums where you can ask questions if you get stuck

6) Present and share (AKA Show and Tell). You now have valuable skills so make sure you pass them on

Finally what about a vision statement for your study to help everyone focus on the point of it (see my other post on vision statements)…

Our team needs a solution for connecting .NET systems and want to avoid writing a bespoke framework, so we need to study the market for open source tools that will do this, so we can save time and cost, unlike our last solution which took eight months to link two systems, we are going to make sure we don’t make the same mistakes.

Kanban and your departments impediments

So you have a department or a Scrum of Scrums pushing out very large impediments all over the place and it just seems to be a sea of problems. How can you focus on priorities that can change frequently whilst appreciating there’s only so much you can do?

Here’s where Kanban comes in. Set a work in progress limit on the impediments you, as a department head can work on, and get the teams to prioritise these. If you can take on two impediments at a time put these on a visible board and make sure they get done. After this take the next most important problems and run in the same way. The teams can re-focus the backlog of issues to keep everyone in agreement and on track!

Presentations – How to get your message across

So you’re writing your first presentation or you want to improve, where do you start? Here are a few tips to help you succeed:

• Are you presenting or sending the presentation?

If you’re presenting you can be a lot more brief in your presentation style and do the talking to expand on your topics. If you’re sending the presentation out then it needs to be self-explanatory and therefore more detailed.

• Consider your audience

Do they want a quick summary, a complex discussion, are they being taught? You don’t need to explain what an alternator is to a garage but you may to the car owner!

• Keep the detail down

A common mistake from people who are very concerned with detail is to cram it all in to every slide, this makes your presentation look like a document. Worse still it may have been a document and you just moved the text across.

• Sell it

Are you trying to get a message across? If you are then treat it like a sales pitch, sell your idea, help your audience reach your conclusions.

• Consider the number of slides

Your director may just want a high level summary with one (yes one!) slide. Your technical staff may want 15 so they understand the problem properly. You may have a limited amount of time to present so consider this as well when setting length.

• Questions before or after the presentation?

Do you want a discussion all the way through or only after everyone has understood your whole presentation? Make sure you decide this up front and tell your audience.

• Know your subject

Stuttering through your presentation because you don’t know enough looks awful. Make sure you can answer questions and talk confidently.

• Talk with confidence and passion

Look up, smile and talk like you would to someone you’re friendly with.

Anyway that’s just a starter for 10, good luck!

Request For Information (RFI) – Help from outside companies

Some challenges can be too great for a company to solve on its own, especially if you have limited resources and experience. Setting your company’s overall direction can be fraught with danger as you could lead it into a blind alley for years with the wrong choices. This is where the RFI (and ultimately the RFP come in but I’ll deal with that one later).

The RFI is the prelude to an official project, you should decide what your main aims are without too much specific steer. You’re not trying to limit a project at this stage, you’re trying to understand the art of the possible. You’re usually asking consultancy firms or those firms with tools that appear to fit what you’re after. For the sake of this post we’ll concentrate on a project with very loose scope rather than something highly specific and potentially well understood (such as a unit testing tool).

• Prepare a document with your requirements clearly stated

What are you trying to achieve, in clearly defined sections. You’ll probably be surprised how often this sort of document shows up the difference of opinion between internal stakeholders. Often everyone seems to be in agreement until it’s precisely written down. Ask the company to reply to your RFI stating how they’ve met these requirements.

• Identify the experts in an area

Who are the main players and who aren’t? It’s very important to understand that if you’re going off for a change in development process you don’t select a testing specialist. This is sometimes a real issue when someone has a favourite supplier and insists they’re included (and even worse chosen!). Narrow the field up front rather than inviting tens of companies in.

• Detail your current set up

There’s nothing more annoying for a vendor than turning up with a proposal to hear “that won’t work here”, just because you didn’t bother to write the detail in in the first place. Assign a specific resource to write sections which detail all the relevant information.

• Keep an open mind

Don’t turn up with a pre-conceived idea of what you “must” have. There could be new ideas out there that are better.

• Have some idea how much you want to spend

Most projects have a budget, make sure you don’t waste everyone’s time. If you need a “proof of value” from a project make sure the vendors know this up front.

• Get project buy in from senior stakeholders before you start

This is really important to keep your relationships with vendors in a good place. Don’t spend lots of time and effort on a dead project. If you are going to do exploritory work make sure you explain that clearly to them.

• Support the project with technical staff

Often the vendors will have further questions, make sure you’ve got people lined up to answer these quickly so the responses can be as good as possible.

• Consider how the project will affect your current teams

Do they need knowledge transfer, are they suitable to take over the work later on? Ask the company to explain how it usually works with other companies.

• Research

It’s always useful to have a grounding in a subject so you’re not blinded by buzzwords. It’s good if you can do some reading up front.

So that’s the RFI, as I’ve said previously there’s an RFP stage after this but hopefully this post will help get you started.