Do you need a portal?
Back in April, I presented some sessions at the International SharePoint Conference held in London. One of the sessions was titled ‘We need a portal’. It was part of the business track, exploring how to run SharePoint projects.
Align your project dependencies
I recently presented at the International SharePoint conference in London. This year, the conference held a new business-focused track and I was asked to present a session titled ‘From Business Requirements to Technical Scope’. It was third in a series of connected presentations. A modified version of the talk is embedded below. (As usual, the original contained media animations and not many words so doesn’t really stand on its own. Soundbite notes have been added into the slide deck.)
I confess, I was convinced I would be presenting to an audience of about 5 people as I had always assumed this to be a very technical-focused conference. I was wrong. The room was packed and the feedback received was great.
The emphasis of the session was on how to tease out the dependencies that should be aligned and prioritised as part of any SharePoint project, to help ensure that desired outcomes can be achieved. It is always about much more than just the technology. To visualise, I used a very simplified causal loop diagram. I may do a follow-up with the more detailed original from which it was taken.
Focus on the destination
The Internet has made business feel more like sailing – operating in real-time and often unpredictable, requiring the ability to continually adapt. Organisations who live by annual plans and budgets are already becoming too slow to respond to change. Read More
Puzzles and Mysteries
When it comes to knowledge-based systems (i.e. ones that don’t work too well without people involved), a lot of the value will emerge as the system is used Read More
A scrummy world
It has been interesting watching the SOA (service oriented architecture) vs Web 2.0 (read/write web) discussions this past week, John Hagel has perhaps the best summary. Whilst I love the overall objective of SOA, my interest has waned as the ‘experts’ have got in on the act. They seem intent on designing the perfect SOA world in theory first and that approach usually leads down a dark path to being expensive and complicated to adopt, with questionable return on investment. Web 2.0, on the other hand, feels much more real in that the applications are out there to work and play with. But the low cost and large number of similar applications makes it almost too easy to start adopting different niche solutions with little concern for their longevity or value, and that approach can stumble across a chasm between consumer/silos and corporate/integrated adoption.
Microsoft hosted an event called Spark in March to look at the connections between Web 2.0, Service Oriented Architecture (SOA) and Software as a Services (SaaS). David Hill has posted his notes. Mike Platt, one of the organisers for Spark, has documented some of the initial architectures that were brainstormed during the event and there is a blog tracking progress. It’s a good start to marrying up Web 2.0 and SOA. Jeff Schneider has created a very good image ‘Competing Interests‘ to visualise the clash between organisations and individuals, business and I.T, and the challenges they face.
The common problem shared by SOA and Web 2.0 is that neither approach enamours IT to business. The Internet is changing how people interact with organisations, speeding up the pace of communications, decisions and transactions. There is frustration at the slow pace of change inside organisations compared to outside, and IT is too often part of the problem instead of the solution. Regardless of whether the preference is for the theoretical and controlled SOA approach or the practical but chaotic Web 2.0 approach, there needs to be closer alignment between IT activities and business needs.
Jack Vinson woke me up to the Theory of Constraints (ToC) and I think SOA and Web 2.0 would make a lot of progress within organisations when accompanied by a ToC statement. The short version of ToC: “Technology is beneficial if, and only if, it diminishes a limitation.” 4 questions to ask:
- What is the power of the technology?
- What limitation(s) will it diminish
- What rules were flawed because of the limitation
- What new rules should be followed
For example, there’s not much point implementing wiki software to improve document collaboration if the traditional method for reviewing reports is a monthly meeting with handouts to review. You have to be prepared to change behaviour as much as the method and to do that requires everyone to be involved, business units as well as I.T.
Once you’ve pass the ToC justification, the solution still needs to be implemented. Too much theory and top-down design risks creating a complicated and/or sterile solution that nobody wants to use. Too much chaos and bottom-up adoption risks causing confusion and duplication, wasting time and resources.
In the software development world, a new method called Scrum is gaining support and I believe the method could be applied to most I.T. projects. It attempts to mesh theory with practice, and align I.T. solutions with evolving business needs. The idea behind Scrum is that when customers define requirements for a project, they are based on an ‘envisioned system’. But that envisioned system is not sufficient for predicting costs because the initial set of requirements sound great in theory but can fail in practice. I have often seen this happen when building prototypes for customers: once the requirements are translated into a working model the customer realises that they want something different, or that their requirements are going to be too expensive to ever achieve a return on investment. The end result is the same – the need to redefine the requirements. But projects are often signed off without any attempt to prototype and costs are based on that initial set of ideal requirements . The implementer (be it internal I.T. or external consultants) is then committed to delivering those requirements come what may, costs and project plans can spiral out of control and, for the biggest (i.e. government) projects, we hear all about it in the news.
The Scrum method assumes from the start that there will be changes to the requirements and uses an iterative process for implementing a new solution. It recognises that whilst the ‘envisioned system’ is needed as the start point for a project, the ‘essential system’ is what will be built. The definitions:
- Envisioned system: a system as initially foreseen by customers to deliver the needed business value
- Essential system: a system with the minimum set of functionality, architecture and design that delivers the envisioned system’s business value
The Scrum method rejects the traditional approach of predicting costs and resources at the start of the project and then holding the project team accountable for delivery of those predictions (and thus encouraging the project team to make it extremely difficult for the business to change requirements, no matter how compelling the reason to do so). Instead, Scrum is a collaborative process that encourages the business to change requirements as needed throughout the project by not requiring I.T. to be rigid in their predicted costs (time, resource, money) up front. By making the essential system the baseline for the project, the business is free to adjust resources required for the project – more funds can help deliver the project sooner, if there is clear business benefit to do so; delaying key milestones can reduce risk when theory doesn’t translate into practice as well as initially expected.
I think the combination of ToC and Scrum can create a framework for better aligning I.T. projects with business needs. Whether those systems are based on SOA, Web 2.0, SaaS or whatever then doesn’t really matter as long as the solution delivers the goods. If the experts defining the theories include alignment with the Theory of Constraints in their models and a Scrummy approach to adoption, it will be far easier to justify and prove their purpose, benefit and value…
Maybe we need to follow the scientists lead – we need a unified theory for doing I.T. 🙂
Related posts:
Additional References:
- Theory of Constraints (Wikipedia)
- Scrum software development (Wikipedia)
- List of SOA vs Web 2.0 posts (Mike Platt)
Knowledge without people
…is an oxymoron. You can’t have knowledge without people or, to put it another way, why would you want knowledge without people? Can you imagine an organisation that contains no people? That doesn’t sell anything to anyone, or buy anything from anyone, or do anything for anyone? What will we all be doing? Wondering around Second Life looking for virtual people to talk to? 🙂
Most knowledge-based systems that fail do so because they try to eliminate the human element of the system. Someone has a vision of the ultimate knowledge database, containing all the information you could ever need. No need to chance the opinions of those pesky humans with their biases and irrational behaviour. Let the computer provide the answers. It’ll be rational, reliable and it will present the results in a nice tidy chart…
I thought we had moved on from such ridiculous notions until I picked up the Saturday Times and read the headline “Pick a doctor by computer ‘fiasco’“. (Full article is available online). It seems that some bright spark in the NHS believed that, in order to prevent bias and favouritism in the allocation of placements for junior doctors, a computer database should replace interviews in the selection process. You can read the full article on line and a more detailed follow up article “Online selection of new doctors ‘grossly unfair’“. In wanting to take out the human element – the biased interviewer – it seems the system was designed to allow self-interviews instead. Of course, when we interview ourselves, we are completely unbiased and rational… (I can recommend some useful ‘brain’ books if you actually think that last statement is true.). Spot the flaw in the system:
The applicants fill in a form online. It is divided into six sections with each requiring two answers, of up to 75 words… passing exams counts for only one sixth of the total possible score and is valued equally with, say, how convincingly an applicant can argue that he or she matches the General Medical Council’s Principles of Good Medical Practice, or how persuasively he or she can pretend to leadership or teamwork qualities… No interviews will be conducted, nor will answers be checked.
Beautiful. Just when we though the tyranny of numbers had finally been outed… Do you think the designer of this system got their job by being matched to it by a computer? I think not. Imagine political leaders being selected using such a form. When it comes to describing their own leadership skills, what would Stalin have written compared to Gandhi? And who would the computer have awarded the most points to? The mind boggles…
I wonder just how many placements in the past have been suspected of bias in favour of the “old boy” network. Surely the best approach is to find a way to handle the exceptions rather than replace the entire system. For starters, if the “old boy” network really does exist, it will still be alive and well. Of course, nobody received help with filling in their forms… did they?
Practical planning
Having been buried in a couple of customer projects for the past few weeks, yesterday morning the sun was shining and I finally had time to ride one of the horses… and naturally spotted some similarities between riding and the projects…
Both projects involved reviewing and updating existing information systems – one focused more on content management, one focused on collaboration, both introducing new working methods into the organisation. And introducing new methods means introducing change.
Project number 3 – Harry, the horse I was riding – shares this last point. Harry has been rested for over 6 months and is unfit with a thick winter coat and not much muscle – looks more like a seaside donkey than the show jumper pictured on my Contacts page. This was our first session together, and the rider’s condition is not much better than the horse, with the exception of the hairy coat 🙂 Some serious change is required.
When you bring a competition horse back into work after a period of rest, you go through three initial steps:
- assess the current condition of the horse: fitness, muscle tone, suppleness
- estimate time to first competition (how much work is required before we’ll be ready for our first event)
- identify target competition (the first ‘serious’ event we want to aim for)
1. Assess current condition:
The only way to do this is to get on and ride, discover what works and what doesn’t. Despite the long rest, Harry went better than expected. Completely unfit, (clipping scheduled for the weekend, goodbye hairy coat), muscle tone not great but not bad, and suppleness is still there (thanks to his breeding – part Lusitano, the breed of horse traditionally used in Spanish bull fights and they are naturally very agile)
2. Estimate time to first competition
Thanks to his suppleness, we’ll get to a competition earlier than with other horses as long as we do some basic fitness and muscle work. Provided he’s ridden regularly, we’ll be ready to start competing in about 4 weeks (normally it would be 6 – 8 weeks)
3. Identify target competition
Here in the UK, we have a Winter National Championships held in April, and he would be ready by then… unfortunately, qualifiers run from October through to 2nd week in March. I should have started 6 weeks ago because we aren’t going to be ready in time for the last round of qualifiers. In a word – tough. The Winter champs are out, so we’ll focus on preparing for the Summer season. The first major outdoor show we usually go to is Leicester County show, held over May Bank Holiday, so that’s our target. Our stretch target will be the Royal Windsor Horse Show, held 2 weeks later with an annual championship class that we will be eligible for this year… and it’s held in Queenie’s back garden, – it’s a cool show to be at. Our ‘quick win’ target will be to compete in the warm-up classes at the Winter champs, that don’t require pre-qualification.
And there’s a fourth step that spans all three – me. As the rider, I also have to commit to change – I’m not much use to Harry if I’m unfit and slopping about the saddle like a sack of potatoes, and I’ve got to be prepared to put in the time and effort riding him – he won’t put his own saddle on and exercise himself in the arena.
So what does all that have to do with I.T. projects? … 🙂
1. Assess current system
Too often, organisations fail to assess what they’ve already got before implementing new systems. I highlighted this in ‘why is KM so difficult?‘. You need to know what you are working with – existing solutions should be examined and a decision made regarding their role in the new system. Understand what those existing solutions actually do – what works and what doesn’t. And don’t guess, don’t make assumptions – find out for real (example: I.T. dept “our people just use Office for basic stuff, word processing and the like”, Accountant: “yup, we pretty much run the business off these 14 spreadsheets…”, Me (on investigation) “you mean, those 14 spreadsheets linked to 100+ other spreadsheets and a handful of databases?”)
Just like with horses, you can’t build an accurate plan if you don’t truly know your starting point.
2. Estimate time to first milestone
How long will it take to provide something (anything) for the business to try out? I often get strange looks from I.T folk when I ask this one. The usual plan is to spend an inordinate amount of time designing the taxonomy, process and other gumpf, and then launch the perfect, tightly controlled, system upon the end-users, perhaps with a small managed pilot along the way. And wonder why it gets ignored as people carry on doing their work as normal…
If there’s one thing I’ve learned over the years with knowledge-based systems, they rarely get used the way you anticipated. You need to test them live, in their real working environment, and then tweak based on the results. With horses, you don’t really know how well the training plan is going until you’ve completed your first competition. Sure, you can hire out an arena and school round a set of show jumps, but that’s just a pilot test. The first competition is the real milestone – seeing how we perform under show conditions. The same is true for many I.T. projects – the sooner you get a live test, the better. A pilot is just a practice run, it’s not real.
3. Identify the target achievement
Most I.T. projects have an end goal, a vision to be achieved (and hopefully a benefits case to prove some return on investment). That’s all fine and dandy, but knowledge-based projects are not 5-minute affairs. They take time to bed-in and become a seamless part of the organisation. A target set 2 years in the distance will seem a long way away at the start of the project. I’ve got an idea where I want Harry to be competing in 2 years time, but to get there I need to focus on the here and now. The same can apply to I.T. projects – identify a strong short-term target to focus your efforts and demonstrate significant value to the business at the earliest possible opportunity. But don’t get all giddy and excited about ‘ideal’ targets. Be tough, focus on what can be done, not what you’d like to do. (Just like I have to accept I’ve left it too late to qualify for this year’s Winter champs.)
Once you’ve got your first big target and your initial milestone, look for the quick-wins – goals that can be achieved along the journey that serve as regular check points that the strategy is on track. Quick wins help maintain momentum and commitment to the changes being introduced – they also provide instant feedback that can help adjust the plan if needed.
And as for that fourth step – I.T. projects cannot be successful on their own, they need the organisation to be fully committed to the change being introduced. Without support across the organisation, any new knowledge-based system is at high risk of failure. Just like with horses – whilst it is the horse that has to do the jumping, the rider has to commit to presenting the horse at the right jump, at the right pace, and at the right time. It’s a partnership.
See, I keep telling people that working with I.T is just like working with horses 🙂
Down the drain
Nicholas Carr has a nice summary on his blog post ‘Down the drain‘ describing why large projects so often fail.
His second point is the classic trap that so many knowledge-based projects fall into:
…Always create software to solve the day-to-day problems faced by the actual users, not to meet big abstract organizational challenges. Solve enough little problems, and the big ones take care of themselves. Fail to make users’ lives easier, and they’ll simply bypass the system (and never trust anything you do ever again).
This has been consistently demonstrated over the past 14 years, particularly in relation to content-management systems. Organisations spend vast amounts of time and resource designing the ‘perfect’ intranet with the ‘perfect’ taxonomy, ‘perfect’ search engine, ‘perfect’ workflow processes, ‘perfect’ metadata set, ‘perfect’ rules for adding, modifying, approving, archiving content (and all its glorious metadata)… you get the idea, and the project fails miserably because it is focused on solving a perceived organisational problem (‘we need a knowledge management system’) rather than solving actual user problems (‘I don’t know who to contact for help on…’, ‘I can’t find previous reports on…’). The end result: people avoid using the system because a) it is difficult and time-consuming to use and b) it does not provide them with enough benefits.
In recent years, I’ve seen customer-relationship management (CRM) projects fall into exactly the same trap. The focus seems to be more on generating lots of reports to support business plans than on helping people improve customer relations. Yet it is through improved relationships that business metrics will be achieved, not from viewing charts about the current state of play. (See also: Seven Productivity Tips)
The most successful information-based projects are typically started by the content users themselves, rather than the IT department or management. They grow bottom-up, with minimal investment, and spread organically through popularity – they are useful, they solve a problem. Instead of being concerned with clamping down and stamping out these projects, the IT department should embrace their benefits and help convert the projects from start-ups to fully supported applications. And that does not mean spending the next 3 years designing and implementing the ‘perfect’ replacement…
Update: FT article describing the successful approach adopted by the BBC, via the person who did the adopting
Better Risk Management
Great article in The Economist (print edition: 20th August 2005), showing how BAA took a new approach to risk management to help keep the Terminal 5 project on schedule and budget. (Something that the UK is not renowned for when it comes to construction projects – think Millennium Dome and railway track upgrades for starters… and then there’s that football stadium in Wembley)
In a nutshell, BAA analysed previous project disasters, and concluded that tying contractors to compensation payments for late delivery and failures might generate money but doesn’t get an airport built. Instead of requiring suppliers to include risk payments in their quotes, the payments are put into a central fund. If the job is done on time, the suppliers get a share of the fund. If there are problems, they are solved using the money from the fund. This also encourages suppliers to work together to fix issues, since all will be affected by reductions to the central fund. BAA says that 80 – 85% of the jobs on site are being completed on time, compared to an industry average of 60%.
There’s more info in the article (including analysis of the potential negatives from this approach), but what a good idea! And what a great way to foster collaboration and cooperation across your supply chain, using a carrot rather than the usual stick.
Article is available online (at time of posting) here:
Blue Skies Thinking
Joining Dots 