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.

There’s an interesting phrase in the PMBOK Guide (Guide to the Project Management Body of Knowledge, 4th Edition) when it comes to the  amount of time activities take to get done. It uses the term “work periods” instead of hours, days, weeks or months. This intentionally broad term is there for a reason. (Though the PMBOK Guide does seem intentionally obtuse sometime.)

The reason it’s so broad is that every project and every general type of activity has its own time period that makes sense for it.  Some activities get done in hours, some in days, some in weeks.

By keeping the term broad, the PMBOK Guide gives us discretion in choosing the time period that makes the most sense for our project. It recognizes the difference between the units of effort required for different activities, and in doing so, emphasizes that no matter what type of activity, project management processes can help. That is, the body of knowledge of project management has something to say about every type of activity, regardless of the length of time it takes to do it.

This is also a heads up that picking the right unit for the time periods on our projects is an important part of the planning and scheduling process.

I was recently interviewed by Cornelius Fichtner’s Project Management Podcast on the topic of how Project Managers are Agents for Economic Growth.

From Cornelius’ blurb:

Mark claims that all project managers are agents for Economic Growth. Really? Cause I’ve managed mostly small and medium sized project throughout my career and I didn’t see myself as an economic growth agent. And most of the companies I’ve worked for also didn’t have the appropriate corporate culture to make me one.

So you can guess that I was a bit skeptical, when Mark first suggested this topic. Let’s hear what he has to say about these arguments and what skills and mindset such a Project Management Agent of Economic Growth needs.

This is a premium podcast but here is the transcript in PDF.

If you have never listened to it, the PM Podcast is an outstanding source for project management information. I highly recommend subscribing to the podcast so you can catch all the great content they produce.

My previous interview on the PM Podcast on Customizing and Contextualizing Your Project Communications is now available to non-subscribers. (The interview starts at around 9 minutes into the program.)

Rolling wave planning works well for software development projects.

There is a high degree of uncertainty when gathering requirements or putting together a specification.  The challenge in finding the right terms alone, leads to many potential misunderstandings between project sponsors, managers and team members. It can be hard to find the boundary terms that mean the same thing to everyone.

Because of this, when its doable, prototyping is worth more than spec’ing.  This can be a UI prototype or a functional prototype or even a screen by screen step-through. But a prototype helps accelerate the conversation between sponsors and team members, and reduces the level of uncertainty (and therefore reduces opportunities for wasted effort).

As an aside, this is often what people are looking for when they turn to Agile project management: repeated prototyping.  What draws many people to Agile is the idea of delivering a meaningful and scope controlled prototype, as fast as possible, and iterating from there.  That is a central concept behind rolling wave planning.

For many of these circumstances, rolling wave planning with prototyping is a better fit.

One difference between Agile and rolling wave planning is that rolling wave planning doesn’t tightly define the turnaround times for delivering features or a prototype.  The project manager is not tied to a pre-defined period for delivering the prototype.  Project managers can select the appropriate time period for each iteration.

A software developer deals with unique situations almost every day.

Every project, every bug fix, every issue has its own unique challenges and one of a kind circumstances.

Even if the functionality has been built before in other systems or is available on other pieces of software, implementing it on a specific system or integrating it with existing code has its own set of challenges.  A developer really does work on “projects” in the sense that they work on unique endeavors that have some degree of uncertainty and risk of failure.

As far as the other side of the formal definition of a project, having a defined start and end date, that’s often a matter of controlling scope creep or change requests

Because developers are working on projects there is no single body of knowledge they can master to have answers to questions right off the bat.

When you ask a doctor about a pain in your side, there is a well documented set of potential answers and a huge body of research on the most probable answer based on other data points/symptoms reported.   They can usually give you an answer off the cuff.  And if not, there are prescribed recommend tests to further find the answer.  This isn’t the case with a software developer.

A software developer is not a doctor. No two bodies of code are the same.

Next time you ask a developer for an answer or an estimate, don’t surprised if they need time to come up with the answer. Or, if the answer they give is inaccurate or if the estimate is off.

The same is true of designers and creative knowledge workers.

A Job List or Project List has the power to keep competing deadlines off your back.

Start keeping a list of every project or job people request of your department. The list should have the project name, the person who requested it, their department, the date they requested it and the date they want it done by.

If you are like most internal marketing departments or internal IT departments, this list will get very long, very fast. It will become the living embodiment of all the competing pressures on you as a director or team member, and of the demands on your resources.

Of course, you probably already keep a list like this for managing your work, for keeping track of all your projects and the tasks everyone has to do.  It might be a paper list or in project management software.

The difference with this list is that this is a list you share.

This is a list that is openly available and public for every “client” to see.

If you are an internal department, your clients are your internal clients and it’s up to you to navigate the political territory.

If you are an independent agency, please don’t really show it to your clients.  Show it to the account managers and salespeople who are asking on behalf of the clients.

It is the list you bring out when someone else from another department asks you to get another project done, to squeeze in another job. It is the list you pull out when they make that job request and you say:

Great.

I’d love to get that job done for you. Here is a list of everything I’ve got going in the department right now. Some of them are from you. Some are from other people. Which one should I bump? Which one should I move to fit yours in?

Wait for the answer.

Nothing gets a process going for better project management or for more thoughtful allocation of resources and better decision making, than making people prioritize the work they want you to do for them.

It is also an outstanding exercise for an independent agency. It helps you evaluate which are the highest value clients, the highest value projects and it can help you better understand what makes them so valuable (so you can do more of that).

The people behind Stack Overflow, the wildly popular programmers forum, has a proposal to host ASK ABOUT PROJECTS at no cost.

Askaboutprojects.com is a leading forum for project management questions answered by a global community of project management experts (including us here at Vertabase).

You can help move this proposal forward at Area 51. This is the “staging” area for sites under consideration by the folks at Stack-Exchange.

If you are interested in project management, or have a project management question, check out the Ask About Projects website.  Its a community driven site where you can ask questions, you can answer them and you get to decide who’s answers are good or not.

Next time your client comes to you with a tight deadline, an aggressive schedule or fast turnaround, ask them “why?”

And if they are coming to you every week with tight deadlines and crunch-times and overnight deadlines or deadlines in hours instead of days or weeks, ask them “why?”

Ask them why it’s such an emergency. Ask them why it’s so important and why they need it so quickly.  And did they have the need yesterday for it? Will they have the need tomorrow for it?

50% of the time they won’t have an answer.

50% of the time they are just getting something off their desk or trying out a new idea or seeing if they can relieve some of their pressures by having something new come out of your department or your team.

(You can usually tell if this is happening when they don’t have time to look at the draft work-product you produced for them or to comment on sketches or mock-ups or even the tweaks you made based on their initial feedback.)

Next time they come to you with super rush deadlines, ask “why?”

And build it into your process.

You’ll get a lot more work done. And your clients will be happier when you have the time to dedicate to the jobs they truly value for their longer-term needs.

Incidentally, “why?” doesn’t mean you’re turning away the work or saying you won’t do it.  The idea is to put a  business case ahead of the expenditure of resources. It’s about prioritizing work so you can focus on the most important jobs and knowing what the work-product is supposed accomplish.

I will be speaking at the November meeting of the Project Management Institute’s (PMI) Great Lakes Chapter. The topic is:

How To Achieve Economic Growth and Innovation Through Linchpin Project Management

Attendees receive a 1 PDU continuing education credit from the PMI.

Below is a description of the session. You can register at here.

Project management evangelist Mark Phillips will bring to life the new buzz-phrase “linchpin project management.” He takes the concept explained by author Seth Godin and defines it in everyday terms, recommending steps that project managers and other business leaders can take to create a culture of linchpin project  management.

Attendees of this presentation will learn the critical distinction between the view that project managers lead “operations” and the view that they lead “projects,” with the latter being preferable.

By seeing their roles as true managers of projects, the individuals in these roles maintain creativity by distinguishing themselves as being in charge of something unique, something that is bringing change and has never been done before.

Finally, Phillips will describe the innovation-driven authority that the best project managers can derive from their roles and provide tips for individuals who want to achieve this level of mastery.

Timothy Keirnan’s Design Critique: Products for People podcast published an interview with Mark Phillips from the Internet User Experience 2010 Conference in Ann Arbor.

The podcast discusses how designers, studios and internal art departments can use project management techniques to create better work product.  The podcast gives real-world, non-technical tips. It also goes into some of the political / personality challenges you might encounter.

If you don’t know about Timothy’s podcast, its about encouraging usable products for a better customer experience. It recently celebrated its 5 year anniversary and has included interviews with such note-worthies as Michael Graves and the creators of SnagIt.