pradeep bnv
BDE| Semantic Space technologies
Hyderabad, India
Hi,
It is been ages since we are following Project management methods which have long planning process and lots of predictions. And we see the same figures for ages like 60% of the projects fail every year. Is it that these predictive approaches are not suitable for s/w projects?
It is always a challenge to develop and implement software based projects which made to put more emphasis on project management thinking more. The main problems come from difficulties in planning, estimating and executing the process while trying to maintain a brisk schedule of releases.
A number of new project mgmt methods have been developed to try to improve the results obtained from these projects with varying success. Of which PRINCE2 for example, is the second iteration of an attempt to manage large IT projects more effectively. Ironically, it is probably more popular in non-software projects than the purpose for which it was intended. May be this is because the tasks are not understood or the requirements keep changing fluidly during the course of the project.
When we compare the same with other industries like construction project where the underlying methodology is known and accurate benchmarks exist for say, the duration of major tasks and the resources required. The success ratio is RELATIVELY high using these approaches
Is it because 'Predictive' approaches like prince2 try to understand and define the future in detail which is not ideally suited to software development?
Pradeep.B
www.ppmstudio.com
Saving Changes...
|
|
|
You've raised a good question, and it's an important one.
The reality of predictive analytics is that the results are only as good as the underlying information upon which any prediction is based... and that's where the problem you've described is born.
Most project management processes address the IMPLEMENTATION-specific issues, but don't adquately perform the upfront, pre-project-definition tasks which belong in the REQUIREMENTS-MANAGEMENT processes, performed by the business-analysis team (and NOT the project-management team.)
The two disciplines are NOT the same thing, and there is (when correctly sequenced) a serial-but-iterative relationship between the two processes. More specifically, the business-analysis tasks that result in the properly-validated requirements need to be performed prior to the the execution of tasks that take place in the project management process. It's a separate skill-set, and should be "business-unit-needs" focused, rather than "technology" focused.
...and YES, it's true that multiple iterations, both in the requirements-management process and the project-management process, can be expected. Neither the requirements themselves, nor the Project Mgmt processes that attempt to fulfill those requirements, are static
entities. Most of the time, both evolve as stakeholder needs change, and the sychronization between requirements and project-execution tasks is, itself, a task to be addressed, planned and monitored.
The 60%-failure statistic which you cite is a moving target, but it's usually an indication that in a given environment, either or both of those two fundamentally-important processes is mistakenly seen as producing some static, finite, immovable set of constraints, which tends to send a message to the project team and the end-users that they only get one chance to nail down specific user needs.
Often, this is unrealistic, and the stakeholders know it.
I'd assert that it's the use of "frozen" requirements or inflexible project management methods that causes a significant percentage of project failures.
Stakeholders who want better results need better processes, and it's the recognition of the separation between these two disciplines that is the most productive "first step."
My suggestion: In discussion with your major stakeholders, take a look at how your organization produces the decisions related to project-mgmt planning tasks, and decide/negotiate how best to prioritize projects, how to ensure meaningful requirements (using methodologies such as the BABOK, which can be found at www.theiiba.com) and then applying proven program-and-project methodologies, whether PRINCE2 or PMBOK. You'll likely find the results to be much more consistent from project to project when you've defined (and followed!) a more formalized business-analysis methodology first, and then fed that validated requirements information into your project management process.
This approach is valid and reliable for both software-dev projects and other types of projects, as well.
If you've identified and engaged the proper stakeholders, and then accurately defined real requirements, the project management tasks which fulfill those requirements become much more readily implementable, and you'll increase the likelihood your project will succeed. Best of luck to you; Start the conversation with your stakeholders!
Saving Changes...
|
|
