Project Management

So I have just finished my second semester at Winthrop University in their MBA program and now have more time to post. I took a course this semester on Project Mangement. It focused a lot on why you need a process and how to put into place a formal process for designing software from initial requirements gathering to testing and user training. We used many examples including several industry standards including(i.e. IEEE and ISO 9000). Each provide great resources for establishing standards in the workplace. To view the ISO 9000: 2000 edition visit this site. ISO 9001: 2000 . It provides a framework for not only defining a process, but working towards an industry standard.

Some standards may include simple things like a process for training new employees or a formal process where you design a formal Statement of Work or a Software Project Managment Plan. The great thing about these is that you do not have to create one from scratch, their are several examples out there free of charge. You do not have to come up with a project management plan on your own, you can use what IEEE has already established and use what is beneficial to your organization. During the semester we stressed the importance of requirements gathering as it applies to software projects. The top three reasons projects fail is due to poor requirements. I encourage everyone to evaluate their process and strive to continuously improve upon it. (And create one if you don't have one in place). This article from IBM , gives many figures for projects in terms of success/failure.

31 percent of all software projects are canceled before they are completed (a waste of $81 billion).
53 percent of projects cost 189 percent of their original estimate.
In large companies, 9 percent of projects are on time and within budget.
In small companies, 16 percent of projects are on time and within budget.

So what does this tell us?

We are horrible at gathering requirements, we are very optimistic about when we can complete a project, And most importantly we need to improve our abilities and spend more time gathering requirements correctly the first time.

In my next post I will focus specifically on how we can improve the requirements elicitation process.