Monday, April 29, 2013

The Secrets of IT Project Success -- Willpower

Stories of failed information technology (IT) projects are legion, and the poor success rates have been documented in many studies.  To some extent, the larger the project and the more time and money spent, the more elusive the success.

I have been mulling over the reasons for project success based on my experience participating in projects and reading about the industry.  Of course there are many reasons for success and failure, but I think the most important one is the willpower of the stakeholders and key project participants.

Nearly all IT projects are challenging, and could easily be considered failures or the project team doesn't adapt to changes in requirements, technology, and other factors.    

The assumption that requirements are finite and stable is unrealistic.  Rigid requirements can lead to project failure, or a product that technically meets the requirements but doesn't actually work.   It's easy to point blame to all the participants in the project, from flawed management vision to weak requirements to sloppy coding and testing.

What stands out to me in successful projects is the sheer willpower along with optimism to ship a working solution, and the willingness to face up to all the problems that are encountered along the way.  This courage is not common, and some projects and organizations prevent individuals from taking personal stakes in the outcome and putting their willpower to work.

Wednesday, April 17, 2013

Don't Call People Resources

I know that in project management, people are considered resources in the same way that raw materials are considered resources, but for software development projects I have found it counterproductive to treat people like so many interchangeable parts.

The success of a software project hinges on the interactions among many people, including the client, subject matter experts, project managers, testers, trainers and developers.  In addition to their experience and expertise, these people bring with them their personalities and communications styles. 

Because software development is more a team exercise, like filming a movie, than an individual exercise, like writing a book, the overall team dynamic is just as important as individual qualifications.   It is quite possible to put together a team of people with excellent resumes who will be quite ineffective when forced to work with one another.

I have run into clients who focus excessively on comparing resumes as if they provide an indication of future success.   Some of the best resumes I have seen belong to work avoiders who spend more time finding others to blame than accepting responsibility and getting things done.  Job hoppers have more interesting resumes than steady performers that stay with companies and projects for the long haul.

So many project methodologies are now used that you need to ensure everyone is on the same page.   Approaches and activities that work in one methodology are disastrous for others.  Excessive love of methodology and documentation over working software is ever more pernicious.

Experience of people who have worked as a team is a great asset for a software project.   Knowing the strengths and weaknesses of team members helps project managers and technical leads assign tasks to the right people, and to know how those people should be managed.   Some need close attention with frequent interaction, and others need time alone to do their work.  Some people will thrive in the intense pressure of a war room environment, while others will crumble.

So even if you call them resources on your project plan, don't treat people like resources if you want your project to succeed.