≡ Menu
Pawel Brodzinski on Software Project Management

What Would Be You PM Approach: Josh Nankivel

Another set of answers in what would be you PM approach comes from Josh Nankivel who is author of PMStudent and is experienced project manager willing to share much of his knowledge.

There are three situations. For each the question is the same – what would be your project management approach?

You work in a big company and are put in charge of big complex project which is about to be started. People in the company are familiar with Prince-2 but time or budget overruns aren’t anything new, although they’re kept at industry average level. A project team is gathered from different teams – they haven’t worked with each other on any project yet.

I can not comment on an approach to project management, but I can say how I would start to figure it out.

• First, what kind of project is this? If it’s an aerospace project with a long life cycle and includes lots of engineers and scientists I may go one direction. If it’s strictly a software development project I may go down another path.

• Related to the first question, what is the makeup of the project team? Depending on the type of people and roles involved, there are sets of methodologies, communication styles, etc. that work better.

• In general, I tend to lean towards a SCRUM-like approach as much as possible, and elements of Critical Chain project management. Daily scrums are great regardless of the methodology you are using, and having some form of a “release” (be it software, documentation, design, etc.) is a great way to get early feedback. With a large and complex team, you will probably split them up by subsystem or other logical grouping so you have no more than 6-8 people per team.

You’re hired to clean up the mess in projects in company of 70 people. So far the company struggles to do any project on time or without major problems. Project management is pretty non-existent and software development along with quality assurance is drowned in chaos.

• Focus groups with project team members, project managers, sponsors, customers, and other stakeholders. Use 5-whys and other techniques to identify root causes of issues. Don’t spend much time trying to address symptoms…those will get resolved after you identify the root causes of failure and attack them.

• Understand that organizational change is a fairly slow process. If you want to change the company culture, you need to identify the problems, come up with solutions, and plan for a transition over a period of time. When people try to initiate instant change, they usually fail. You need to steer a diverse group of people and the culture they have built….and that takes a good strategy implemented over time. There should be significant milestone goals and reflection along the way so everyone can see how things are improving. It will get them excited about future changes. You want raving fans that actively participate in the transition and help it along….not people who feel like change is being imposed on them against their will.

You organize a startup of four people, including yourself. The idea you work on however puts pretty strict requirements when it comes to software performance, high availability and quality. The team isn’t going to grow for some time but in a perspective of year you hope to see a dozen people on board.

I lean towards Agile methods, especially since this sounds like a software start-up. Be strategic and make sure your process is scalable if you have a goal of future growth. Do not implement process for the sake of it. Process should only exist to the extent it adds value…period.

Check out the rest of the series.

in: project management

0 comments… add one

Leave a Comment