Paul Boag, one of the founders and directors of Headscape, once said; “We specialise in sh*t projects.”

If, like me, you run projects for a normal, every day web agency. If you do not always get the opportunity to be working with the latest cool technology or utilize the next whizz bang idea. If you don’t build sites for rock bands or the latest cool technology start-ups. How do you keep you team excited and enthusiastic about their day jobs? After all, if your team is not interested in the work that they are doing then they will not produce the high standards that you need and that they are capable of. This in turn is demotivating and you end up in a downward spiral.

How do you get your team excited about a project for brown paper bag manufacturers?

It doesn’t belong to you

The first thing to do is to promote ownership of the project within your team. Let them in on the solution. It can be tempting at times to solve (or try at least) all the problems yourself. It is much better to get your production team (designers and developers) in on the act as early as possible in the project. Do not present your designers with a list of things to do. Instead, give them a collection of problems that their design needs to solve. Do not dictate the technology that your developers must use. Instead give them the information that they need to choose the most suitable tools for the task.

Allow your team to shape the solution and they will take pride in the result. Let the project be their project. Not your project.

Express yourselves

The second thing to do is to allow your team the time and space to express themselves. Allow them to be creative; to try a new technique in a real project situation. Even if it is something very small in the grand scheme of the project it can act as the signature of your production team. This mark of ownership will inspire them to make sure that even the most mundane of projects can be the best that it can be.

Allow your techies to experiment with the new features of the latest programming language release. Allow your designers to put in that extra fun element that will only work in in the latest cool browsers. Give them the space play with a real project in a real life situation.

Using a new technique or a new technology can be enough to provoke the interest of your team. This means that the website for the brown paper bag manufacturers can be the most exciting project that you team has ever been a part of.

Slaves to the time line

Alarm bells are ringing. What about the time line! We have a deadline to meet.

And quite right too. These extra bells and whistles cannot get in the way of real targets and delivery milestones. However, if you build some time into your schedules to allow for this kind of experimentation you will have a happier, more enthusiastic and, ultimately, more productive team.

This will also encourage your team to keep developing their skill set knowing that they will get a chance to use their new found talents in real projects leading to a higher quality of work over all.

Is this something that you have tried? Or as a designer or developer have you tried to sneak little Easter Eggs into your work just to make sure that you still have a pulse at the end of the day? Let me know.

A big, if not the biggest, part of my job as a web project manager is dealing with clients. This is actually the part of the job I enjoy the most and see the client as, very much, a part of the project team. I have found that an honest and transparent approach is best when dealing with query’s and problems and involving clients in the general processes of the project (as much as they are able) leads to a smoother road for all concerned.

I have said this before but I see a PM’s role as one of facilitation. I need to enable people to do what they are good at and I need to, wherever possible, stay out of the way. To some extent, this includes client communication.

The ambassador

I recently read a good post by John Reeve; Project Managers: Why every creative agency needs one. In this article he talks about the PM’s role of ambassador. A go-between between the client and the production team. While I agree that this can be necessary at times I see this as only a temporary role.

As PM I need to be aware of all communications. I need to have  a complete overview of the project and understand what is going on when and who needs to do what next. This doesn’t mean that I need to be a middle man. While I still hold on to my technical routes, the chances are, when a client has a question or a problem of a technical nature I will not know the answer.  I will need to go and ask the tech team. Similarly, with a design based question, I generally have no hope without first consulting the design team. So why should I get in way?

Expose your team

We have found it useful to introduce the client to the team at the earliest possible stage in the process. Wherever possible the lead designer and lead tech on a project will be at the project kick-off meeting.  The team will take a lead in conference calls where questions or discussions are to be had about their area of expertise. As long as I am kept in the loop then there is no reason for me as PM act as messenger boy.

When this process works well the client feels more connected with the process and, as they get to know the team, have a greater level of confidence in the the time-scales, quality control and ultimately, the deliverable.

Obviously, some relationships are difficult. This is where the role of “ambassador” goes on for longer than is ideal. As PM it is important to spot and manage these situations so as to still produce the required results and get the job done. I have found this to be a rare scenario.

Openness and transparency as an approach needs to stretch throughout the structure of the project. This includes exposing your team to your clients.

What is your experience?

As a designer or a developer, what is your experience of  dealing directly with a client? As a client, what is your experience of talking directly to production team members or maybe your experience of not being able to? PM’s, do you have experience of this approach going horrible wrong?

I’m often asked questions about the differences between working with designers and developers. Today an article I wrote for boagworld.com was published which takes a brief look at this question.

Don’t Reduce Your Designers And Developers To Stereotypes

Risk, in the land of project management, is anything that could potentially get in the way of your project going according to plan and being delivered on time.

There are two types of risk; those that you can do something about, and, yes you guessed it, those that you can’t.

Let me give you some examples from my world as a web project manager at Headscape. Let’s say we have been asked to deliver a project to facilitate a small, but growing, web presence. The client has existing content which needs to be edited and integrated as well as new content that will be supplied by them. The client uses a third party system; previously not used by us but similar to systems we have used before. This third party system needs to be updated by the application we develop.

This is a limited, but not uncommon, project request. So what are the  main  risks here?

1. Content
   Content is always a risk. The single biggest reason why a project is delayed at Headscape is content. Clients never, ever, appreciate how long it will take them source, edit, and deliver content.
   This is a risk that is completely out of your control.
2. Third party system
   Whenever a third party system is involved (especially one that hasn’t been used before),  no matter how similar it is to current systems, you have a risk. There will be a learning curve for your team, documentation will most likely be inadequate, and there is bound to be a new release half way through development that will break everything you have managed to get working.
   This risk you can do something about.

Risky Business

Having located the risks what can we do about them?

Highlight them with the client from the very start. If you make the issue of content clear from the beginning, for example, it might, if you are really lucky, mean that the client will take it on board and actually deliver what they need to on time. Failing that it makes it a lot easier for them to swallow if it does end up being the reason a project is delayed.

Talk about potential issues with their third party system. Do not be afraid to present these to the client. My experience has been that, in the main, they appreciate a transparent approach.  You can legitimately build in time to the project timeline to allow for the research and learning involved. Even so, there is always an element of the unknown here. If something is going to go wrong with this project, it will involve interfacing with this third party system.

Build in contingency to the budget and the time line. You can not remove the risks but you can plan for them.

It’s easy to fall into the trap hoping that all will go well and you will have project that follows all the best possible scenarios.  If you close your eyes, and wish really hard, then you can sell a shorter time line and it might just work out for you. However, if you plan for the risks and build in the required contingency, you might even deliver early.

Clients love to be surprised like that.

As PM’s at Headscape we have started to work together  to launch each new project with a project risk assessment. Highlighting all the things that could be a risk to the project running smoothly. Things that are both internal and external to our environment. Things that we can do something about and things that we can’t.

Being aware of these risks and planning for them has had a big impact on our ability successfully set client expectations and deliver projects on time, and on budget.

Paul obviously ran out of interesting people to interview this week and so rolled out the perennial plan B. Me.

If you want to listen me talk about the joys of Project Management the checkout the latest boagworld.com podcast.

http://boagworld.com/podcast/158/