When I look back over recent projects that I've been involved in, it seems that one key to making a project successful is having someone on the team who really drives it forward: someone who is invested in the project as a whole and not just their own part in it.
We (by which I mean the University's Applications division) have a well-defined project process, with defined roles, required milestones, deployment standards, and so forth. All these are useful, but if the team doesn't have a leader, it seems a project can lose its way, perhaps not responding to changing circumstances, getting stuck on a technical problem, or not securing a needed resource in time to meet some external constraint.
The leader can be any member of the team - it could be a developer, a project manager, or the sponsor, or someone in another role. A team can include several people who are this committed to the project; it doesn't have to be a single person.
As an example, one of our senior developers instigated our programme to develop frameworks for APIs and notifications. In addition to leading the technical design, he explained the vision, and co-ordinated other people's contributions. The management team supported the work with funds and effort, and other team members played a role, but he was the driver. When he left the organisation, the programme floundered for a while until a new leader stepped forward.
An example where a project failed through lack of leadership is one that I initiated. I saw a need to review how our identify management system treats people who have more than one role - e.g. someone who is enrolled as a student and who is also employed by the University. I got the project set up and kicked off, and then left it to the division's project process - but no-one on the small team really took charge and made it happen. The project sent out a survey only a week before students left at the end of the year, which was too late to get a decent response. Resources got called into other projects and the team only completed half the scope before the end of the financial year put an end to the work. No-one on the team was behaving badly or failing to do the tasks allocated to them, but neither was their anyone who was seeing the big picture and making the project succeed.
It takes time and commitment to make a project succeed, and the way we structure our work can make this difficult. We allocate people to multiple projects, with the aim on using all of everyone's time as effectively as possible, so that if one project has a delay, others can proceed. But the result of this is that projects end up competing for priority, and some end up unloved and forgotten.
I think we may do better to put more emphasis on leadership and a making sure that the leader(s) on a project have sufficient time and support to make each project succeed.
(As a reminder, I'm now using this blog for my personal reflection and thoughts. For official posts, see our blog for Enterprise Architecture at the University of Edinburgh ).
We (by which I mean the University's Applications division) have a well-defined project process, with defined roles, required milestones, deployment standards, and so forth. All these are useful, but if the team doesn't have a leader, it seems a project can lose its way, perhaps not responding to changing circumstances, getting stuck on a technical problem, or not securing a needed resource in time to meet some external constraint.
The leader can be any member of the team - it could be a developer, a project manager, or the sponsor, or someone in another role. A team can include several people who are this committed to the project; it doesn't have to be a single person.
As an example, one of our senior developers instigated our programme to develop frameworks for APIs and notifications. In addition to leading the technical design, he explained the vision, and co-ordinated other people's contributions. The management team supported the work with funds and effort, and other team members played a role, but he was the driver. When he left the organisation, the programme floundered for a while until a new leader stepped forward.
An example where a project failed through lack of leadership is one that I initiated. I saw a need to review how our identify management system treats people who have more than one role - e.g. someone who is enrolled as a student and who is also employed by the University. I got the project set up and kicked off, and then left it to the division's project process - but no-one on the small team really took charge and made it happen. The project sent out a survey only a week before students left at the end of the year, which was too late to get a decent response. Resources got called into other projects and the team only completed half the scope before the end of the financial year put an end to the work. No-one on the team was behaving badly or failing to do the tasks allocated to them, but neither was their anyone who was seeing the big picture and making the project succeed.
It takes time and commitment to make a project succeed, and the way we structure our work can make this difficult. We allocate people to multiple projects, with the aim on using all of everyone's time as effectively as possible, so that if one project has a delay, others can proceed. But the result of this is that projects end up competing for priority, and some end up unloved and forgotten.
I think we may do better to put more emphasis on leadership and a making sure that the leader(s) on a project have sufficient time and support to make each project succeed.
(As a reminder, I'm now using this blog for my personal reflection and thoughts. For official posts, see our blog for Enterprise Architecture at the University of Edinburgh ).
Comments