Making projects work: project change and perceptions of failure

by Elizabeth on 8/06/2009

This is part one of a video series on making projects work, looking specifically at the impact of change and how that contributes to the perceptions of project failure.

The talking heads are BCS Managing Editor Brian Runciman and three CEOs: David Hicks of Radtac, the lovely Melanie Franklin of Maven Training and Paul Major of Programme Framework.

Watch part two tomorrow!

If you liked this, you might enjoy:

Making projects work: personnel in the project This is part two in the Making Projects Work video debate, which talks about teams and people. Part one was yesterday, and there next bit...
Making projects work: is project management too complicated? This is the third part in the Making Projects Work video debate series. It’s a really short video, and it looks at whether or not...
Making projects work: achieving project success This is the last part in the Making Projects Work video debate series that has been running this week. It’s short enough to watch during...

http://www.lap31.com Raj Menon

Very informative discussion. I really liked the part where Melanie talks about Program Management and the mindset has to change to “move things around” to manage keeping business objective in mind rather than project objective. Paul Major also touched upon an important distinction of Program Vs. Project Mgmt. Being a Program Mgr myself, it is very educational and reassuring. Can’t wait for Part 2, Elizabeth.
http://community.ca.com/blogs/ppm/ Pradeep Bhanot

I liked the point Melanie made on focusing on accepting change being the norm for project requirements. I have seen some individuals take this a step further in formalizing the project change management process, by considering each change as a “defect” and engaging a well defined incident and change management process, whether it be a change to scope, requirement document or timeline. This is especially applicable to the iterative nature of agile segments of a project.

I also agree that IT projects invariably lead to a business benefit, so why belittle them with an “IT project” label.

The PMO having a variety of methodologies to apply depending on need of a specific project.