Many web projects end up in a conflict between the 'business units' and IT.

Why is that?

I found the inspiration for this article when I recently joined communexions (a new community for intranet managers). When setting up my profile I was asked:

Who’s right most often? HR, IT or Communications?

I answered this:

The departments that are correct are the ones that best work together. I have seen many bad examples.

- But at the end it are the people who have to do it, not the departments.

- The department that is most right, employs people that best try to understand others and actively try to work together.

- These departments have a culture where sharing (knowledge, ownership and responsibility) is actively promoted.

I tried to give a longer answer but there was no more room available. But this topic intrigues me already for a long time and I can't stop thinking about it.

Never trust the IT department.

I have seen many intranet presentations and had discussions with many Corp Comm and Marketing managers. A lot of them had bad experiences with their IT department.

These are things they usually say:

• The IT department is slow (outsourcing is cheaper and quicker)
• IT does not have the expertise to build it
• IT does not understand the business needs

I also had many discussions with people in IT departments and this is what they often say:

• They never know what they want - they keep changing their mind.
• The business plan is not realistic
• They involve us too late
• It doesn't fit with the strategic enterprise IT direction

Both are right

Actually both parties are right, but what I really noticed in the discussions was a lack of trust in the capabilities and intentions of the others on both sides. This is a management issue and it is not so hard to solve. But people have to step over old grieves.

1. For every web project involve the the main stakeholders before the project actually starts. 
2. When all parties are on the same level, then write the business case together (yes, together: this is the key point where you start sharing responsibility and ownership).
3. Now identify all the limitations of the project (budget, timeframe, missing skills) and choose the right project methodology for this project. 
4. Next take all the people that actually do work on the project and put them together in one room (Yes, mix the IT people with the business representatives). And very important: If people are not working on the project, they should not be in the room.

HEY, THIS IS NOT NEW - We already know this. 

Indeed these are common practices and many corporate organisations have strict policies for following project management methodologies and development frameworks.

But in many web projects these simple and well known practices are not followed. (Actually it is not a complete bad idea to follow a different project methodology and framework for web projects than for corporate business applications - But never skip the first 3 points mentioned above).

Another common mistake made with web projects is that managers still believe that corporate web applications are easy. "My nephew of 12 can do it". Please read my post Corporate Web Development is different in which I explain why corporate web applications are not easy - especially intranets.

My experience

I share my experience on a recent intranet project I was involved in; how we organized it and what we learned.

We had to rebuild an intranet from scratch, because the previous intranet did not add any value to the organisation. We had to make it relevant for the organisation.

For the first release the focus was on information sharing. It had to be rolled out to multiple offices in multiple countries and it should support multiple languages.

This project had limitations. The work should be finished in 5 months (for concept, design and build). And there was no project manager assigned for the first 2 months.

The development staff was small, but very senior - usually this is an advantage, not a limitation.

An external party was involved for defining the intranet strategy. This was particular important because that third party stood above the internal departments, and we all agreed on that role.

But the greatest factor in making this project a success was that we were all sitting in the same room. The IT people, the third party consultant, the content managers and the testers. Everything was done in that room. Representatives from the business had to come down to that room to be interviewed or trained. Sitting all together in that room kept the conversations short. The programmers could argue loud, but when there was any little bit of doubt, the intranet team was present and could clarify things and participate in the discussion. And vice versa.

Updated: 12 May 2010 An interesting related article from Peter Richards: Who owns the intranet. That should start us thinking as well.

Updated 21 May 2010: More about the relationship between IT & Business Units

- Enterprise IT plus social media plus cloud computing equals the future

- Three Common Mistakes in Pursuit of Enterprise 2.0 & the Next Generation Workplace Part 2

Updated 29 May 2010: I really like this post - By the way, this site has a nice lay-out - check the homepage!

- Software Developers: The New Rock Stars of Marketing

Final thought  

At the end it are people who have to do it (and that is YOU and ME). And often that is more important than procedures or methodology. People need to want to work together... TOGETHER!

If you have an opinion about this article, especially why you think IT is doing it wrong or why Corporate Communications or the Marketing department is doing it wrong, please post a comment below.