Inspired by a talk on "Project Design" in San Diego .NET user group tonight, I feel the urge to write about past experiences on projects. The inspiration may not be in the form intended by the speaker, as I felt extreme happiness in not sharing values he communicated about big up-front design and class division of non-coding architects and replaceable developers. But something he said triggered my memory: never being on a failed project, or project that would be over budget, late from schedule or delivered with bad quality.
In one of my past places of work, there was a project manager most people admired and liked. I liked him, as he was a very nice person to talk to and was driven, making things easier for people in his projects. His reputation after years of doing his work was that his projects succeeded.
As we worked in the same company, on same level for years, I had a chance to observe what might be keys to his success. He seemed to have identified a great recipe. He would always choose which project he would manage. The project would be one that was of utmost importance for our employer. If the project need something to succeed, that would be given. Often at the expense of other projects around, having to give up their critical people on critical times. One succeeds but all other ones fail.
Just like the speaker today, this project manager would go around telling people he has always delivered his projects on schedule, but making it also very clear that the "on budget" part means the latest approved budget, which could be significantly different with where the project started from. In public, I don't recall him mentioning the detrimental impact his projects had on other projects around him, but in private he was smart enough to see that.
In the session today, the speaker mentioned developers being assigned to other projects before start of system testing - a pattern that usually spells catastrophe in my experience. I've seen the bugs hidden and pushed away until they surface in a later project. One person's catastrophe can be another's success: project completed on time and budget and scope, and bugs fixed in a new maintenance project for twice the hourly rate might sound ideal from the contractor's perspective.
There's this whole field of illusions, that need dispelling around projects. If we find ways of delivering continuously to production, the need of a "project" goes away, we manage a process instead of project. We deal with reality instead of plans. The project managers, architects and test managers with status may not always like it, but instead of paying 5M for a 1M project just so that a person of status can "always deliver on time, budget and scope/quality", we could stop accepting the mediocrity that self-fulfilling bloated plans drive us to. We could accept that software development includes learning on all levels. Requirements don't change as much as we think, our understanding of them evolves. Sometimes our understanding evolves so much that we'll actually require a completely different system.
We really need to think about people: what kind of environment makes us, together, deliver the best possible solutions. I have hard time believing big design up front would have much to do with that.
In one of my past places of work, there was a project manager most people admired and liked. I liked him, as he was a very nice person to talk to and was driven, making things easier for people in his projects. His reputation after years of doing his work was that his projects succeeded.
As we worked in the same company, on same level for years, I had a chance to observe what might be keys to his success. He seemed to have identified a great recipe. He would always choose which project he would manage. The project would be one that was of utmost importance for our employer. If the project need something to succeed, that would be given. Often at the expense of other projects around, having to give up their critical people on critical times. One succeeds but all other ones fail.
Just like the speaker today, this project manager would go around telling people he has always delivered his projects on schedule, but making it also very clear that the "on budget" part means the latest approved budget, which could be significantly different with where the project started from. In public, I don't recall him mentioning the detrimental impact his projects had on other projects around him, but in private he was smart enough to see that.
In the session today, the speaker mentioned developers being assigned to other projects before start of system testing - a pattern that usually spells catastrophe in my experience. I've seen the bugs hidden and pushed away until they surface in a later project. One person's catastrophe can be another's success: project completed on time and budget and scope, and bugs fixed in a new maintenance project for twice the hourly rate might sound ideal from the contractor's perspective.
There's this whole field of illusions, that need dispelling around projects. If we find ways of delivering continuously to production, the need of a "project" goes away, we manage a process instead of project. We deal with reality instead of plans. The project managers, architects and test managers with status may not always like it, but instead of paying 5M for a 1M project just so that a person of status can "always deliver on time, budget and scope/quality", we could stop accepting the mediocrity that self-fulfilling bloated plans drive us to. We could accept that software development includes learning on all levels. Requirements don't change as much as we think, our understanding of them evolves. Sometimes our understanding evolves so much that we'll actually require a completely different system.
We really need to think about people: what kind of environment makes us, together, deliver the best possible solutions. I have hard time believing big design up front would have much to do with that.
