I see no reason why we won’t so long as we follow a similar approach.

Its a credit not to the project management process but to the team of talented and committed individuals involved in project delivery – the Customer Experience team, the design agency, the Amazon developers and advisers, our external testing team and more.

The approach basically boiled down to:

1 – having a committed team of  talented people from across different organisations, empowered to work together and JFDI in order to get their areas of work completed to time and quality, and supported by myself and others to quickly resolve any blockages where needed. Its amazing what empowerment can do for motivation.

2 – top-down planning – a simple high level plan (more like a road map) with key milestone dates supported by more detailed plans for certain activities and deliverables where needed. Plans that the whole team understood and bought into, with dates they signed up to and were willing to go for.

3 – a good set of working relationships across the teams, lots of open communication – phone calls, face to face meetings, etc – and people being prepared to give and take around their roles and responsibilities, being flexible where needed to get the job done. Jobsworths were frowned upon – if someone had the time to do it, or it made more sense for them to do it because of their background knowledge, they got on with it and did it if it resulted in a better quality product or us remaining on track.

4 – everyone wanting success – Everyone wanted to deliver the project on time and within every team, people worked ridiculous hours, weekends and so on if it meant we kept on track. It probably helped that with each new milestone, I reminded the team responsible that we were on track to date (green) and that they might not want to be the one to turn us amber.

Fear of failure also does wonders for motivation!

So what did I personally do?

1 – Fortunately I have what I think are very good working relationships with the others in the  “project management team” – both the head of CX and the Amazon Dev manager. Between us, we helped keep the project on track by reaching decisions quickly, being pragmatic and having open, regular communication.

Having good relationships with each of them helped me to try and build trust between the different organisations, reducing the pressure on teams from others and giving them a little flexibility and space to get their work done.

2 – I kept my nose out of the detail unless necessary to keep the project on track. We had people on point for certain deliverables or milestones and the extent of my involvement was to get weekly status updates from them and have chats with them on an ad hoc basis to get a feel of how things were going. But I also encouraged them to raise things with me quickly if they had a blockage that needed clearing.

3 – I pulled together a high level plan (more like a road map really) and ensured that everyone involved bought into it. Once work was underway on one set of deliverables I let the teams get on with it and looked ahead to the next set, ensuring we were ready for work to kick off, again looking for risks and issues and working to remove blockages in advance of when work was due to start.

4 – I kept asking myself what could go wrong with a certain milestone or set of activity, and then worked to guard against it. Whether it meant getting more closely involved, producing a detailed plan with the team concerned, chewing it over with the management team, whatever.

5 – I talked a lot. I played diplomat in encouraging  individuals to trust, I played referee in disputes between organisations, I played taskmaster when it came to getting work completed on time, I played leader where needed to motivate the team and help them see the way forward and I played watchful observer when someone else stepped forward to sort something out.

In many respects I felt more like a sports coach than a project manager – prepare and empower the team and let them get on with playing while I look ahead to the next game – with a focus not on winning just the game but on winning the competition.

So roll on phase 2 – it might not be green all the way but we will deliver on time! Let’s JFDI, team.

Placing more importance on the process than on the outcome.

I’d rather be called a “project delivery manager” – where the focus is more around ensuring the project gets delivered on time, on budget and to the appropriate level of quality for the customer than on producing a hefty report each week to explain why the project is late, exactly which line in the 1000 line project plan we are up to and how we are 67.56% complete against plan).

And I must be doing something right because my project is one of the few that has been green since it started – and will hopefully still be green when it goes live next Friday. And any projects I’ve delivered in the past have usually also been green.

So what’s the secret?

Well, I mentioned to someone a few weeks ago that for me, successful project management is primarily about managing people and relationships in order to get the job done, not about managing detailed processes or creating loads of paperwork to show what we are doing. And about using your brain and judgement. About ensuring lots of good communication, managing conflicts, unclearing blockages and doing practical things to maintain project momentum.

Relationships

Build healthy relationships with both stakeholders and suppliers and ensure open, transparent and regular discussions from day one. Good, effective, open communication is absolutely crucial.

Build an atmosphere of trust – to the point where they both trust you and each other to do the right thing even when they aren’t clear themselves what it might be. Remember, all 3 have an interest in the project being delivered – work together, not against each other.

Be prepared for conflict, as it will happen – but deal with it quickly and effectively and don’t let tensions build up across this important senior team.

Teamwork and empowerment

Have a clear vision and scope for the project, supported by a high level plan showing only the milestones and deliverables, and ensure the entire project team understands and buys into it all. The whole team has to understand the project vision and scope, and feel the project is achievable (“our project”). If anyone doesn’t, encourage discussion around it and work to gain their support.

Give team members responsibility for appropriate deliverables and milestones (or entire workstreams) and leave them to get on with doing it. Don’t micromanage – instead, empower these smart people to get the job done and get short, regular status updates from them on progress.

If things start to look like they are going off track or risks and issues start appearing, that’s the time to step in. If things are ticking along fine, leave them alone to get on with it.

If a milestone looks tight, suggest they produce a detailed plan to build up to it, and keep an eye on progress against it.

Encourage a team atmosphere where collaboration replaces directives, where trust replaces the need for back covering and where flexibility and teamwork replaces jobsworth behaviours.

Risk and Issue Management

As project delivery manager, this is the area I tend to focus on most. I am always looking ahead across the high level plan, checking for any potential bottlenecks or problems that may be looming and then working in advance to remove them. At a previous employer, some of the team used to call me “the plumber” for this reason – I was forever removing blockages so that projects could maintain momentum.

If issues come up, bring the relevant people together quickly to sort them out. And don’t stop until you have an agreed way forward to resolve them. Time is critical where an issue is concerned or a decision needs to be made – otherwise, things quickly grind to a halt and team morale dives.

If risks are identified, quickly discuss and agree actions to mitigate. Never have an open risk on the risk register without an owner or mitigating actions for it.

And don’t just look for project risks and issues, also watch for dependencies with other projects or wider things going on (holidays, mandatory departmental meetings) that could affect the delivery of your project.

The key is speed – don’t sit back while time ticks on, identify issues and risks and deal with them quickly.

Communication

Like many, I hate email. There is way too much of it. And I particularly hate emailing / being emailed by people in the same office as me. If it can’t wait and you think you might forget the point you wish to make, send it. Otherwise, wait until a time when you can have a face to face conversation about it. Or even a phone call. Face to face / phone helps build relationships – misinterpreted emails often help destroy them.

Have weekly meetings with the team – what have you done since the last meeting, what are you planning to do before the next one, and what issues do you need to table. Add any new risks and issues to the risk and issues register.

Minimal project management documentation

The main ones I feel are beneficial to project delivery are as follows:

- project charter – in my view, the most important one for the project as it sets out the vision, scope, milestones, deliverables, key risks, dependencies, delivery approach, roles and responsibilities.

- high level project plan, showing deliverables, milestones and key tasks only. It doesn’t go into too much detail – if you need it, create separate detailed plans for the team to work against. The purpose of the high level plan is to provide a general guide on project progress and an indication of upcoming activities, not to specify in detail what tasks need doing and by when. ie. it’s not a workplan.

- project budget – keep it simple, summarised and up to date. But don’t overanalyse it.

- status reports – again, keep them short, simple and to the point. If you truly know the status of your project, if your high level plan is up to date and if everyone is in agreement on status, risks and issues, producing this should take less than ten minutes each time.

- risk and issue register – the things on here are those that can really derail your project so keep on top of them and follow through to resolution.

The most important thing is to focus on delivery, not process. Don’t document a failing project, deliver it effectively and hopefully it will never become one.

He sums up the dilemma currently facing organisations.

He suggests that work = fun when you are able to choose where, when and how to work and you have the right organisational structures and toolsets (mostly web 2.0 tools) in place to support that choice. And when you have challenging problems to solve and can work collaboratively with whoever you need to work with to get the job done, and share common goals and achievements.

The crucial point about this is that the new generation of workers (“net-geners”) coming through expect that type of working environment to be the norm. Organisations that don’t sit up and take notice of the needs of their future workforce, which have or are growing up with the web, are going to find challenging times ahead.

From the article:

It’s a case of the irresistible force meeting the immovable object. The net-geners arrive at work, eager to use their social networking tools to collaborate and create and contribute to the organisation. However, they are shocked to find technological tools more primitive than the ones used in school. The organisation still thinks the net is about websites presenting information, rather than a Web 2.0 collaboration platform. Then the organisation bans Facebook at the office because it suspects net-geners are chatting with friends and throwing digital snowballs when they should be working – thus depriving net-geners of their link to friends, to fun, to colleagues. Pretty soon, they head for the exit.

His article was inspiring.

And having now worked for several large companies, I’m becoming more convinced that many companies of a large size are just not shaped right when it comes to implementing web changes or responding to the challenges of a “web 2 world”.

I’m particularly referring to marketing and IT departments. And here’s why I think that.

IT

I maintain my dad’s website. Whenever he wants a change made to it – anything from creating a new page to editing a photo or pdf – he just sends me an email. One email. And I plan the change, implement it, test it and deploy it within a few days. He then takes a look at it and if its not right, I change it again until its what he wants. Short and simple.

I suggest it takes at least 10 times as long, 10 times as many emails (and number of people involved, conference calls, documents and meetings required) to get the equivalent change done in many large organisations, especially where IT is largely centralised.

Hardly “agile”. Not the most responsive. And totally wrong for our growing web 2.0 world where web changes have to be implemented quickly to retain competitive advantage, and are hard to define completely, in advance of starting to implement them.

No wonder business people continually complain about the time it takes to deliver online projects.

Yes, I appreciate the need for process, risk management, governance and so on but a total waterfall / PRINCE2-based approach to managing IT change just doesn’t work for the web. It really doesn’t.

I would agree it is necessary for big corporate system changes where the risks may be bigger and where requirements can be quite clearly defined up-front in order to help manage them, but its not right for web changes where changes are sometimes small, and often the ideal solution isn’t known until its seen.

Using this methodology for web changes, in my view, also stifles innovation. People just can’t be bothered navigating the Change Control process that is usually a part of it if they happen to come up with a better solution mid way through development.

The solution seems to me to be simple – adopt more agile and collaborative ways of working when it comes to doing the actual “from requirements to development” part of a web project.

Create smaller cross-functional, multi-skilled teams and empower them to deliver the best solution for the business. Remove as many layers of bureaucracy for them as possible and just let them get on with it.

What’s the worst that can happen? Create some / minimal controls to guard against this – but don’t go overboard. And clearly define the integration or hand off points where the code developed in the “agile” world needs to be passed back into the “waterfall” world to be tested and deployed on the corporate IT infrastructure.

Best of both worlds, perhaps? Combining speed and innovation with governance and risk management.

Marketing

The other day, when talking about his website, my dad happened to mention an enquiry he received through it from a new customer in Perth. He then went on casually to say that he put the customer in direct contact with his supplier in China so they could discuss the enquiry (about product spec) directly, and in more detail.

Customers / suppliers talking to each other. Without the organisation.

I thought about how difficult it would probably be to do that in many large organisations, and pondered why this was the case.

Now I’m definitely no expert in marketing but I think its because in typical large organisations, you probably have whole departments whose purpose is to manage the brand and  the messages around it. Its historical, from when messages could be controlled and sent one way only. The thought of customers and suppliers now talking about their products without their knowledge and therefore without being able to influence the discussion is probably quite worrying to them.

Not sure if this is something about a lack of trust (why do many organisations seem to naturally think that if given the chance, customers will say bad things about them??), but I doubt its sustainable in a social media world.

This is traditional marketing. Web 2-based marketing (also known as social media marketing) is multiway, participatory and user-generated. Its also loads cheaper and I suspect more insightful.

And I think its the future.

And totally not what many large marketing departments are probably about. They’ve got to change, to trust the conversations that will happen or are already happening and to become a part of them. There are loads of opportunities for customer insight, surely.

What do I define as a “web 2.0 friendly” organisation ?

Well, for starters it’s a place that values empowering staff to make their own decisions around how to do their jobs above enforcing tight controls, rules and security over what they can do. Naturally you need to consider these things – pity help the organisation who doesn’t have strong firewalls these days.

But it’s a place that tries to get the balance right to encourage staff loyalty and stimulate innovation while also managing business risks. A place that actively shows their staff that they both trust and value them whilst also having some safety nets in place if / when things go wrong.

A place that has a very flat structure and comprises self-organising ad hoc groups (rather than organisational divisions / depts) that form the way they think best around business opportunities and then disband when done.

Examples:

- a place that has blogs and wikis for knowledge sharing but minimal guidelines about usage beyond those needed to protect the organisation’s reputation and exposure to risk

- a place that lets employees make their own decisions about the tools they need in order to best do their jobs

- a place that is process-light and provides an environment to encourage doing over talking

- a place that lets employees create their own knowledge sharing structures, groups and systems, e.g. adopting folksonomies and social networking tools for business use

- a place that provides employees with access to a range of data sources and lets them make decisions on what to “mash”.

Wikis, blogs, communities of practice, instant messaging, flat structures, light processes, self-organising teams, hands-on approaches to getting things done, working when you need to  and where). All good stuff, conducive to getting the best out of people.

That’s my type of organisation.

So I thought I’d use this blog to jot down my thoughts as they develop and if anyone happens to read it, hope its been of interest to you. I guess there have been loads of books written on the subject by people who are much more authoritative on the area than me – if you know of any good ones, let me know!

Reading Wikipatterns recently, and Wikinomics before that, really set me thinking about the way businesses use web 2.0. (I’m taking baby steps at thinking this through so bear with me!) And having done the rounds of a few workplaces over the past year I’ve seen some interesting examples and reactions to the new technologies.

It made me realise that where web 2.0 is concerned there are (at least) three main types of organisations:

1 – those who treat their staff and customers as adults: they trust their staff and customers to use the tools sensibly, not to abuse them, and I guess they generally think positively when it comes to allowing their use. They might have company Facebook pages like this for their customers etc to join, virtual places in Second Life (like Michelin apparently do) for staff training, they probably have fairly unregulated internal wikis, unrestricted web access and maybe they allow staff to simply install the tools they need (IM, webmail, etc.) to do their jobs and have their own internal / external blogs if they want to.

I would imagine these places to be where you’d find things like the use of Agile methodologies (that welcome changes in requirements), family friendly policies that trust people to work when, where and how they do best, and flat org structures that encourage leaderless cross-functional teams to self-organise around problems. They trust their staff, they trust their customers – and I guess they trust in the quality of their brand.

These are probably the sorts of places that Generation X and their next lot are most likely to want to work in.

2 – those who treat their staff and customers like unpredictable teenagers – anxiously trusting them, only because they feel they need to, but being prepared should they misbehave (almost expecting them to) and hence having some controls and restrictions in place. They probably allow limited instant messaging use, allow web browsing (but restrict access to some sites, such as Facebook) and although they have an internal wiki, probably have loads of rules and guidelines for how they should be used.

With a bit of luck, and the right management, these orgs should hopefully turn into type 1′s as they build their trust.

3 – those who treat their staff as children who if given the chance to misbehave, will do. They almost certainly don’t have a wiki (what’s a wiki), don’t allow Instant Messaging outside the organisation, look nervously upon blogs, don’t understand RSS, mashups or social networks and don’t feel they need to.

They are probably very hierarchical, measure their staff on their inputs (working hours) rather than on their outputs and have lots of nervous IT managers trying to keep the lid on web 2 use.

I imagine that these will eventually die on the vine as generation X’ers and so on are probably unlikely to want to work for them.