Another technique I’ve been using to increase Agility in our production process is to be less patient with team members when a customer’s need is not met. This has shifted the focus of the team directly on creating value to the customer. Agile has breathed new life into this classic management principal, from Peter Drucker (perhaps because Agile ties it directly to project management and a production process rather than remaining an overarching corporate philosophy).
Cultural boundaries have become less important using this approach. We operate in a culturally diverse environment. People have different definitions on what it means to put in a good day’s work. By rating performance directly against customer value, people’s perspectives have started to converge and cultural backgrounds matter less. Problem solving becomes the focus. Each person brings their unique talent to the table. Constraints like cultural norms or a person’s title fade into the background.
We’ve been adding more Agility into our production process here at Vertabase. As product manager, I’m leading this effort. One of the techniques I’m using is to push-back at the development team when they ask me questions, particularly about features.
One of my favorite responses is “Do I need to make a decision on this now?”
The urge to make a decision now is strong, coming from a plan driven background. But it unduly locks-up the team, our customers and our product.
While it is comforting for the team to have me (or a customer, for that matter) make a decision, it makes them less nimble and responsive. It focuses them on meeting a set of requirements, as opposed to the customers’ needs. The responsibility for the feature is no longer in their hands. They can simply follow directions and meet a spec.
So far, the team has been empowered by seeing that a decision doesn’t have to be made nor a policy/spec adhered to, and re-focused instead, on the simple art of the right feature implemented well.
I’m a big fan of project management methodology. However, applying formal project management to marketing companies can be difficult. One of the challenges marketing firms have in adopting project management methodologies as described in the PMBOK Guide (The Guide to the Project Management Body of Knowledge, 4th Edition) is that they aren’t often described in terms of the types of projects marketing companies or art departments do every day. Nor is the order of events generally the way marketing companies work.
One example of this is the classic approach to time and schedule development. In the PMBOK Guide, a project’s schedule is determined by the number of resources applied to the project and the types of resources applied to a project. This seems to be a hold-over from manufacturing or engineering (or other projects where the degree of uncertainty is much higher). But it doesn’t apply to a marketing department. For most marketing companies, a project’s schedule is determined by the client. The client has a specific due date where things have to be ready by to coincide with a holiday season or product launch, event, sales presentation or trade show.
The due date is the same, regardless of the number of resources applied to the project or task. It needs to be done by the due date.
This gap often drives creative groups to look at Agile project management processes since it sounds faster and looser. The problem with Agile for marketing companies is that the work doesn’t easily fit into the length of a sprint. The deadlines for a marketing company need to remain determined by a client’s needs or a strategic decision on timing.
For most marketing departments or agencies, neither process nor resourcing decisions drive deadlines. Clients drive deadlines.
That being said, not even the PMI would argue that every step of every project management knowledge area needs to be used on every project. The PMBOK Guide is a collection of different best practices held together by one model, one conceptual set of guidelines, rope on how they can all fit together. But there are many ways of applying the techniques and ideas to different practice areas. And specific practice areas, like marketing, should piece together what works best for them, balancing the benefits of proven and tested processes with the need to meet clients’ needs and to operate as efficiently as possible.
We were having an internal meeting to pick a project management methodology for a web project we are working on for a new client. As developers of commercial software, our instinct was to lean towards an agile based approach where our process would be:
- Make an initial feature list
- Get time estimates on each feature
- Prioritize the list
- Time box the development effort
- Build and test as much as possible in that time
- Launch
- Get user feedback
This works great for a tightly defined set of deliverables and a client who has done software before. However, that’s not what this project is nor the profile of this client.
Read the rest of this post »
