My article

“How to Use Social Media to Build Valuable Business Relationships”

was published today in eWeek.

You can improve your decision making, resource management and project scheduling by using percent complete instead of a task list and done/not done status.

Percent complete gives you a status. But it also lets you understand how you are doing relative to your planned schedule, planned number of people on the project and planned costs on the project.

On a job by job basis, you can plan better.

Not only will you know if something is done or not done (and therefore what other tasks need to be completed).  But, you will also know how much work or time or dollars will be needed to get the un-done tasks done.  And, if they’ll be on schedule or on budget.

Longer term, by using percent complete, you’ll be able to notice trends on how well different types of tasks get done or not, the amount of work it takes to get them done and where bottlenecks or cost overruns happen.

This information will allow you to get even better at the work you do.

Which, of course, directly affects your ability to take on other projects, complete existing projects and shift resources to new projects sooner.

There comes a point in any growing organization where you have to shift from calendars as a primary project management tool to metrics.

That point comes when the volume of work, number of resources working and granularity of tasks exceeds any person’s ability to “just eye-ball” project status and resource availability on a calendar or, even on a chart.

Your skill-set then needs to evolve from juggling tasks and keeping things moving to developing project metrics that adequately capture the relevant information on a project so you can a) still keep things moving but also b) have enough information to make plans for the future. These plans include resource allocation decisions, job scheduling, budgeting and taking on new initiatives.

Most organizations generate this kind of information but lack a framework to help collect or use it efficiently (without making a whole other job out of it).  This is were project management as a discipline can help, as well as project management software that provides a framework for information.

The shorter the communication, the more careful you have to be.
That’s why many successful politicians cultivate the ability to talk for hours on end and not be pinned down to one particular point.

Email, text messages and twitter can be dangerous ground for miscommunication. If you are using those tools to speak to your project’s client or sponsors, you have to be doubly careful. Those communications form the client or sponsor’s expectations.

Communications set Expectations.

Misinterpretation and unmet expectations can easily happen, leading to a decline in your relationship with the client or sponsor.

To effectively use those tools for project management, you have to be certain of the parameters and flexibility around the relationship. The relationship should exist well before-hand and have room for the ups and downs mis-communication can bring.

Otherwise, make sure you use the phone more or even have face to face meetings. This gives you room to answer and ask questions, to read your client’s expressions and better understand the expectations set by your communication. Plus, it’s a great way to build a long lasting, personal relationship.

When building a trust relationship don’t try to win.

Trust is built in a relationship by meeting expectations. You either meet them or you don’t. You can’t talk your way into someone trusting you just by showing them how right you are. People have to come to their own conclusions. That’s how they’ll grow to trust you.

Forcing your conclusion on them may bring acknowledgment, or resentment, but it won’t bring trust.

This tidbit can be helpful for project managers to keep in mind when dealing with sponsors, stakeholders, customers and team members. It comes compliments of a presentation by Pam Hansen at the PMI Great Lakes Chapter.

Innovation is critical to economic growth.

To budget for innovation, include the following items a part of your project charter and as part of your project goals.

• Increased team flexibility
• Increased team cohesion
• Increased knowledge sharing

All three of these are important components in having high functioning, high performing teams. High functioning teams, with a high degree of knowledge sharing, are a  basis for innovation and for surviving in today’s innovation-driven world.

By including these goals in your project charter, you assure that even if the project gets canceled midstream or fails to meet other goals like the scope, budget or schedule, if it will have met those three goals, the project will not have been a failure.

This is different then picking “innovative” projects as part of your project portfolio selection process.

When you allocate resources to “innovative” projects you are making a determination that you are willing to accept a higher degree of risk on these projects because you anticipate a higher reward from the successful delivery of the project’s goals. However, you are still counting on the successful completion of the project, and if it fails, you would judge the project to be a failure.

I would argue that the probability of failure on “innovative” projects is similar to that of less innovative projects. At least 50% of them will fail.

By adding team cohesion, flexibility and knowledge sharing as goals for the project itself, you create a culture where projects can “fail” according to more traditional metrics (delivery to scope, budget or schedule) but where the expenditure of effort on trying to accomplish the goals is still worthwhile.

This creates a radically different approach to being innovative.

It gives an organization the strength, creativity and organizational skill-set to continually innovate and continually try new things. Your efforts become focused more on value creation rather than on cost control and the illusory management of outcomes.

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.