42

I read a blog recently on the definition of project success and was surprised by the definition. The definition, based on Pier’s experience with agile development, is when the customer is happy and when the project team is happy and satisfied. I will probably be vilified for this, but I disagree. A project can be very successful and the project team miserable. I don’t recommend it, but it is true. The project is paid for by someone. That person(s) defines the success criteria. Whether they use that criteria or not is a different issue, but let us assume they do. If you meet those criteria, success; if not, failure. Further, depending on those criteria, it is possible for degrees of success or failure.

It may seem incorrect to discount the project teams opinion and I personally do strive to keep my teams happy whenever possible, I have had the experience many times to be on projects I hated. We all get them. The military is practically comprised of doing projects people do not want or like to do: ditch digging, latrine duty, kitchen duty, patrols, and so on. The corporate world has the same. Some of the most common ones that I have seen are report generation, end of month / quarter / year tasks, the entire Year2K problem, and the management quid-pro-quo deal (in which a manager agrees to lend a team to do something for another manager). As a manager, I have assigned projects to teams knowing they would be unhappy, but the work needed to be done.

I will even go further. I have seen vastly successful projects in which the client was not happy or satisfied. This happens frequently in world of finance IT. Many clients frequently expect miraculous turn around times, clairvoyant development teams, and the ability to absorb feature creep without any impact to delivery schedules. Many of the tasks are not even what the client really wants, but what they need to support settlement or legal & compliance. The project team & the client see it as a necessary evil and delaying their whizzbang new feature.

So whats my point. Not all projects are the result of client wants, but the result of client needs. These projects also need to be successful, but very few will make the project team happy or the client happy.

Late last year I stumbled over a podcast entitled Manager Tools. I listened to the first few podcasts and then for lack of time I stopped listening. Time passed and for reasons I don’t fully understand I remember Mark (one of the two podcasters) stating how poorly most managers manage their time. I realized he was right. I also realized that while I dedicated a tremendous learning effort into my technical skills, I put almost no effort into my management skills. After some reflection, I noticed that I used my management skills more often then I used my technical skills. I am not sure why I had not realized it prior to that, but sometime over my career I changed from a developer to a manager. I still needed my technical skills, but I needed my management skills more. This was like an epiphany to me. I decided to reallocate some of my time towards improving my management skills.

This is where Manager Tools kicks in. I remembered the podcast, subscribed to it, and was truly impressed. I have gone back and started listening to it from the beginning. I am still playing catch-up on the podcast and the forums. I have also started going through their recommended book lists. This book list is superb. They have eliminated so much of the noise currently in the management book arena. The books from their list that I have read so far have already made an impact on how I do my job. Combine the impact of their podcasts, and I have been able to increase not only my capability and productivity, but my marketability.

Lastly, Mike (the other podcaster) & Mark are extreamly responsive. They are truly passionate in their goal to improve managers through highly practical techniques. I highly recommend that anyone, in any stage of their management career, listen to their first three podcasts. These first podcasts cover One-On-One (O3) meetings between a manager and his directs. The impact of adding these to your standard regiment cannot be understated. Listen to the podcasts, read the forums, and then do it.

Eventually I will listen to all the podcasts, then I plan to start over at the beginning.