One vital role of the leader is to define and enforce the processes that the team will follow. I've seen more projects fail as result of getting this wrong than any other single cause.

Do I have the definitive answer as to the process you should follow? No, I do not; and neither does anyone else, regardless of their expertise and experience.

The main problem I've encountered is leaders and project managers who are familiar with one particular method and believe that it can be applied in all circumstances to all projects.

Instead, team leaders need to take into account the environment in which their project exists: what experience does the team have? What are the expectations of the stakeholders and customers? Only then can sensible decisions be made as to the processes which the team should adopt and the tools they should use to do so.

However, please don't think I'm telling you to do whatever you like. Sensible decisions on process require a good knowledge of the tools and techniques that exist. You do need to know something about waterfall methods, about PRINCE2, about critical chain methods, about agile methods, about SCRUM and XP.

Don't be afraid to mix elements from all. Many will tell you that you need to chose between agile and waterfall. Nonsense. PRINCE2, for example, has plenty to say about how to propose a project, how to sanction it and how to define it. I've seen many agile projects where those techniques would have been invaluable if applied to each ticket on the issues wall - the project overall may not have been a waterfall project, but the individual issues could easily have been treated as such.

In conclusion, learn as much as you can about the main processes that already exist, but don't become evangelical about any of them. Instead, look at the circumstances that are specific to the project you are working on and the team you are leading and design your processes around them.


comments powered by Disqus