andrewjdumont.com

Project Management, From an Engineer’s Perspective

Posted on 12. Dec, 2009 by Andrew Dumont in Biz Dev, Random Musings

Over the past year, I’ve been taken through a crash course in the world of project management with the launch of Tatango 2.0 – from Scrum Methodology to Agile Software Development. For those of you that don’t know, project management in the tech world is the process of planning out necessary site changes, speccing out what those changes will look like and finally implementing them. But the thing that I realized very quickly about project management, is that it’s all about communication and making sure everyone is on the same page, at the same time.

Because of this, I think it’s important to understand exactly what an engineer believes is the role of a project manager. Many project management teams fail because a lack of communication and understanding of each other. So, I’ve called on my good friend and colleague Adrian Pike, who is the CTO at Tatango, to give us his perspective.

When trying to get a software project out the door, it’s your job as the project manager to have the 10k view of everything that has happened, is happening, and needs to happen, all the while trying to wrangle potential problems or roadblocks that are completely out of control.

One of the things that can be most frustrating is trying to bring together all the players in a way that both benefits the project and
keeps everybody on speaking terms after launch. Even if you’re able to empathize with all the possible viewpoints, you still have to discover ways to relate it to the rest of your team. Maybe you’ll have to translate technical limitations to your support staff or community managers, get testing engineers on board with faster revision cycles, or even convince your system administrators why the new whizbang platform that they’re so hesitant to deploy will save the company thousands of dollars.

Good project managers definitely have a hint of the anthropologist in them – they’re able to understand the different stakeholders, as well as understand the goals of the project on a technical and/or business level.

At Tatango, some of our fastest development was run under a loose Scrum model, which is an iterative development model borrowed from the software industry. It helps define roles for stakeholders, and responsibilities and expectations for those roles, taking some of the interpersonal magic out of the PM process.

There’s lots of other frameworks to help get a project under control and underway, and they all have different strengths and weaknesses.

One of the things that I picked up along the way was that lots of people will try to stay completely rigid on the model, because “it’s proven” and “it’s the model”. This is definitely a way to set yourself and your team up for hardship, as every project, every company, and every team is all a little different. Adjusting your framework to your teams needs is crucial.

What I like to do is treat the process just like a product in and of itself. Look for weaknesses (Scrum is great to help with this by forcing retrospectives), figure out what can be done about those weaknesses, and implement them. Bring in aspects from plenty of frameworks if need be, or stay really lean – it’s all about what works best for your team.

Toyota is a great case study, they spent a lot of time and effort building their process, and along the way grew to be one of the largest automotive companies in a relatively short time. By analyzing their process just like their products, Toyota was able to bring to the table Lean manufacturing, JIT, and finally creating an entire philosophy for the company that maximized output from input.

One last thing I’d like to touch on – lots of classic non-software frameworks for process management talk about “manufacturing units”. When we’re talking software, the “manufacturing unit” is good code, when we’re putting our business hats on, our “manufacturing units” are defined by the overarching business metrics and goals; usually revenue, users, or even sometimes valuation. Managing a software project is all about understanding these goals, and working on devising how to maximize output for all the stakeholders involved.

It’s hard, but it’s also great fun to get something launched that you helped create!

Conclusion – Project management is a high stress process, with a lot of moving pieces. To be successful in project management, you have to understand the strengths and motives behind each person, and work to facilitate them. Technical jargon aside, project management is about communication. As the project manager, it is your job to open the lines of communication between team members and create an atmosphere that harnesses the strengths of each member. Remember, a team that communicates is a team that succeeds.