Open Project Management - Open Management Practices

These practices have one thing in common, they are about keeping the project open. Information should be transparent. Everyone should know what's going on, at all levels of the project. The presentation of the information may change depending on the audience, e.g. summaries for management, detailed specifications for developers, but it should all be accessible by anyone on the project.

Team Dynamics

The first and most important part of the project is creating the team. Jeff Deluca (inventor of Feature-Driven Development) talks about building the system that will build the system. What this means is a group of people with clear roles, responsibilities, and a framework for working together to produce the end result. The team is the system that will build the site. If the team works well together, the project will go smoothly. If the team doesn't work together, the project will be difficult, regardless of what process you use.

Who's on the Team?

You'd expect a standard team to consist of a Project Manager, an experienced eZ publish developer, a designer, and perhaps a system administrator. If that's what you expect, you're missing a very important element—the project owner. That's the person who makes the calls on what can be cut, what can be moved to stage two, what extra features have to be added (with the appropriate cost and time increase, naturally). It's a mistake that is very easy to make. By excluding the client, project owner/sponsor (or whatever term you use for the person that has the final say), it sets up the potential for a negative dynamic. I call this the "Us" and "Them" syndrome. It's an easy syndrome to fall foul of; it only takes a few requests or changes of mind to get a developer's back up and suddenly the developer starts cursing every time the client comes into the room to check on what's happening.

As a Project Manager, I've also fallen for this trap and ended up avoiding meetings with the client so that I didn't have to continue to explain why any change would cost more money and take more time. All I did was avoid the inevitable and made it worse. The key is to realize that everyone is actually on the same team; it may not feel like it at times but the reality is, everyone should be trying to achieve the same thing, a successful outcome! If not, then you've got a serious problem to solve.

It's important to build trust and respect between all the people on the team. It may not be possible to achieve this 100%, and in those cases, it's a matter of finding ways to minimize the impact of any negativity. If that means changing roles or changing people on the team, then just do it. A motto I learned from Jeff Deluca about project management is simply do "whatever it takes" to get the job done (within the bounds of the law of course!).

In terms of practical steps, the most important is to make sure roles and responsibilities are clear. Simple and effective yet not that common in practice. Sure, we all know what a designer and a developer do, but on a particular project, these roles can differ depending on the nature of the people involved and the project itself. So, the goal is to have a page that outlines all the roles and responsibilities and who has been assigned each role. On smaller projects, one person may play multiple roles; on larger projects, multiple people may play the same role. What matters is everyone knows what their role is, and what they are responsible for.

Project Sponsor / Client

Responsibilities

  • Defining and approving project objectives

  • Reviewing and approving project deliverables

  • Realising project benefits

  • Approving / rejecting change requests

Assigned To

 

Reports To

CEO

Project Manager

Responsibilities

Project wide management of planning, tracking, reportingand quality management

  • Issue & risk management

  • Planning

  • Progress reporting

  • Scope change management

Assigned To

 

Reports to

Project Sponsor

Designer

Responsibilities

  • Creating visual layout (photoshop)

  • Creating web images

  • Building css

  • Ensuring accessibility AA standard

Assigned To

----

Reports To

Project Manager

Developer

Responsibilities

The developer is responsible for the configuration of eZ publish and implementation of custom features.

  • Design features

  • Code features

  • Unit testing

  • Debugging

  • Creating templates

Assigned To

 

Reports To

Project Manager

System Administrator

Responsibilities

  • Ensuring systems are configured and operational for project

  • Setup of dev & preview environments

  • Maintenance of dev & preview environments

  • OS configuration

  • Web server configuration

  • Ez Publish install

  • Ensuring system meets performance requirements

Assigned To

----

Reports To

Project Manager