Non-Technical, Non-Certified, Non-Agile Project Management Philosophy
This blog is about my project management philosophy. In other words, what have I chosen to be — or maybe more so, what I have chosen not to be — in my project management style? Project management should not be invasive in the creation process. It should facilitate the team’s end goal and is something/someone that people welcome because of how much more value is delivered by having project management involved.
I am a techno geek. Gadgets and apps are fascinating to me. I want the latest and greatest versions and releases. I can even help my mother with her tech issues (usually without undue frustration). But, I am not a software developer.
I understand “geek speak” so I can communicate with developers. But more importantly, I speak English, so I can communicate with clients. Being able to bridge that gap reduces misunderstanding and frustration. I can sit back and see the big picture, rather than work in the weeds of the code, which is a huge benefit.
I love structure, and I understand contingencies. I want to set milestones and deadlines clearly and to communicate well. However, I am not a PMP (Project Management Professional).
PMPs seem to be more invested in making the method work, rather than making the project work. In other words, they are more about the project management philosophy than about the need to make things happen.
I’ve watched them build beautiful Gantt charts, but the methodology often prohibits them from creatively figuring out how to proceed. Meanwhile, the team can struggle and fall behind due to a lack of direction on real-life tasks. We all wish things always happened in the right order. And, that the work is never delayed based on the plan. But, usually, when the plan goes awry, you have to start solving problems creatively.
Certain fields (IT, engineering, etc.) require certification, so it has value there. But, just like I don’t ever want to use Microsoft Project, I don’t want to build a Gantt chart either. I’d rather be working with people to figure out how to make it happen, rather than drilling down into the minutia of project planning methods and slowing down progress. (Don’t get me wrong… there are times in a project when you need to slow down! And, yes sometimes you even need a Gantt chart.)
I like breaking projects down into smaller phases so faster progress is demonstrated and value is delivered more quickly. Weekly status meetings and cooperation between client and developer are imperative to project success. I am committed to customer satisfaction. But, I do not follow the Agile movement.
Despite my desire to be flexible, I think the Agile method allows you to go with the flow too much. It has a place and time and works great if you have the right situation and client. But for standard software development projects, it is very time consuming for the client and can result in projects that go on forever. The target moves too frequently. I prefer a better-defined project upfront, even if it is a small phase.
I invite my fellow project managers, many of whom disagree with me, to chime in on the comments section below and share their project management philosophy as well. And for the record, there are just as many valid reasons for going the opposite way than for going the way I chose.
Originally published at Beyond the Chaos: Small Business Project Management and Operations Consulting.