Would you tell your project team that it is OK to not get the product working because real-life experience is that sometimes things don’t work out?
“‘Real-life experience [for a professor] is important,’ [he] said. He believes the point in this type of class is not to get the product working — because that doesn’t always happen — but to teach students how to work together ….” “It’s Not Just About Coding Anymore,” Software Development Times, March 2011, pg 30.
Breath. OK, I actually understand the point being made, but I just don’t like it. I’ve seen too many organizations, teams and projects where a failed effort (e.g., not on time, budget, quality, functionality, etc.) was normal and accepted. It has always worked this way I would hear, and it is just something we have to live with. The organization gets by, at least for awhile — and sometimes for a long time, with this kind of performance.
Possibly I had an advantage in that I started to do software programming at a fairly young age and worked on my own projects. I wasn’t bound by time and resources and could get it done whenever I got it done. I also started a lot of projects that I never finished, in large part because I lost interest in them. The point to all this is that I could see what it takes to complete a project and I knew what it was like to finish a project and have it working just the way I wanted it to work. When I got to college I did pretty well in the software programming intensive classes. When I turned in my compiler project (i.e., write a programming language compiler) the professor told me it was the best he had ever seen. Gee, I must have been someone really special!
Nope, I don’t think so (just ask my wife!). I simply had more experience at doing complete projects (and more coding practice) than others had at that time. The key was completed projects. I would finish a project and then spend weeks and even months tweaking it to get it just the way I wanted it. I knew what it looked like from beginning to end to do quality work.
When I got into the professional world, doing computer programming, I quickly came to a depressing conclusion. The conclusion was the project problems are not technical. Since I knew how to get things done, and done fairly well, my own initial inability to get things accomplished was frustrating.
Why did people (e.g., managers, technical leads, etc.) keep getting in the way of just getting the job done? Meetings about things that have nothing to do with what I was doing! Assigning or not assigning people to tasks due to questionable motives (e.g., friends, not friends, promotion opportunities, complaints, control issues, etc.)! Over controlling who knew certain information and who was involved in key decisions! What the heck was going on here? Wasn’t our purpose to accomplish the mission (we were in a hybrid military-governmental-contractor organization)?
With determined effort and the blind naivete and energy of someone in his 20s, I was able to get the organization to deliver their software intensive system on time and with good quality (for the rest of the story see making the leap). So my second conclusion was that an organization could break out of their malaise and do great work. My career would take me through many organizations where these same patterns were evident and accessible to change (for more on change see silver bullets).
So working together is in fact incredibly important and one of the key reasons we were able to break the first pattern (e.g. managerial bad habits) and implement the second (e.g. on time projects with good quality). However, breaking the first pattern was always the biggest challenge and the ability for people to work well together was always self evident by them achieving the second (also see self managing teams).
I just would not emphasize to students that since it is often normal for projects not to succeed that it is OK if they don’t succeed in their assignment. I’d rather our university system teach our students how to complete a successful project by working together and then mention how many teams still struggle to achieve the same.
How do you motivate a team to be successful in an environment where many projects are still not successful?