Welcome to the project jungle baby! Just to clarify: the project on context of this posting does not mean anything fun. It's meant to resemble something that usually has manager, a steering group maybe, usually more self claimed stakeholders than you have fingers. From perspective of continuous improvement, that is not a project really. It is a deathtrap.
And it goes on on smaller scale as well. If your business mostly relies on projects, big or small, and even more so on continuous flow of projects, it's quite possible that you've knitted a dulling little trap.
Project, as a state of being, is static. It's a profoundly self aware ecosystem, which has little tolerance to outside world. Most of it is seen as a threat to project's survival. Still today most of the projects, because of our general relation to customers, are mostly assembled beforehand. Staffing, milestones and stuff is documented a bit like railways are constructed from point A to point B.
<<<<<<< HEAD
To continue the train metaphor, persons who the think have the situational awareness (project managers, team leads) have merely the role of engine driver: There's not whole lot to do. And when there is, it's mostly related to immediate things surrounding the project. In rather dire situation, the role of the front line project personnel is to act a change blocker.
To continue the train metaphor, persons who the think have the situational awareness (project managers, team leads) have merely the role of engine driver: There's not whole lot to do. And when there is, it's mostly related to immediate things surrounding the project. In rather dire situation, the role of the front line project personnel is to act as a change blocker.
3ad6d5fa81104f197ed027f7249790963fea45be
What comes to the development of developer team, the project is a massive deathtrap. Project obfuscates; It's far too easy to mirror everything in par with the project, and its peculiarities. Standard issues, like communication problems manifest themselves in project context, reflecting the attributes of that particular project. This is especially true when communicating with remote participants, different teams or such. It's too easy to dismiss all problems concerning only the remote side, since they'll be around only as long as the project will last.
This is whole lot to analyze in order of finding root causes. Most often this is neglected in favor of faster execution: time for analysis is between projects. That time will never come. Even if it will, the window of the effect has long passed, until it bites back in the next project.
Haste kills. Haste is the poison in project deathtrap, and haste is the reason why you won't improve.
Project is a vampire by nature. It sucks up the energy of positive change, by forcing you to battle for your own survival. When project is nearing its end, the hunt for next one begins. It may be straight continuation for the current one, where you'd get marginal benefit for reflection in project scope. Usually though, premises change, otherwise there's very little reason to start a new one. The energy you need for reflection and change is wasted on pure survival. Thus, the survival instinct of project personnel is the enemy of improvement. If you've worked on larger IT service company, you know exactly what I mean.
What to do
<<<<<<< HEAD If you do something that even remotely resembles product development, stop making projects. Just stop.
If you are a project house, level down the responsibility. Team is functional unit, and can work itself through obstacles and deliver what is needed without babysitting. Mostly there's no steady pace. There is average pace, but the energy that is wasted on trying to keep up the average pace is all out of efforts to improve. Play it low without hush and mush, and try to keep the context fixed to work at hand. Don't run improvements as projects, since you will kill your chances for sane follow up.
If you do something that even remotely resembles product development, stop running projects. Just stop.
If you are a project house, level down the responsibility. Team is functional unit, and can work itself through obstacles and deliver what is needed without babysitting. Mostly there's no steady pace. There is average pace, but the energy that is wasted on trying to keep up the average pace is all out of the efforts to improve. Play it low without hush and mush, and try to keep the context fixed to work at hand. Don't run improvements as projects, since you will kill your chances for sane follow up.
3ad6d5fa81104f197ed027f7249790963fea45be
Think about work. Don't think about the project goals, or the road map, but think about the work at hand that needs execution. Better yet, what has been executed an what can be learned from that. Do not optimize your project. That won't last. The only change worth pursuing is a long term change, and that takes determination beyond project.
Running projects without teams? No future.