AtTask

I see on Twitter all the time lists of the best project management software, the best business intelligence tools, or the best portfolio management products.  I thought I would toss in my two cents today.

The polish poet, Stanislaw Jerzy Lec said, "The weakest link in the chain is also the strongest.  It can break the chain."

When most organizations consider project and portfolio management tools, they look at visibility and business intelligence tools for validating that execution aligns with corporate strategy.  This is important, even critical, but most project software misses the point.  It ignores the end user, the person who is actually in a position to input the most accurate data.  This oversight forces project managers to spend the lion's share of their time chasing down status instead of leading project teams and facilitating successful projects.

Addressing the needs of individual project team members is the crucial link (weak or strong), that determines whether or not the information business leaders use for making decisions is accurate or a bunch of bunk.  Making it difficult for team members to contribute to the project management process just doesn't make sense—and virtually guarantees that information will be out of date and unreliable.

What's more, organizations that rely on any solution, including project management software that doesn't automatically capture status information simply can't guarantee that decision-makers have accurate and up-to-date information.  They might as well continue to use a spreadsheet and sticky notes.

In my opinion, when looking for project software, I think it's critical to include the following criteria in your evaluation:

1. Does the solution address ease-of-use needs for end users?
2. Does the solution automatically push project status information into reports and dashboards that executives can use to make data-driven decisions?
3. Or does if force project managers to manually input data, duplicating effort, forcing them to ignore their primary responsibilities to keep projects on track and lead project teams?

Admittedly, these are only a few of the questions you'll need to ask as you evaluate the available project management software solutions—but they are critical questions if you want to effectively engage the workforce and enjoy success.

I don't believe the workforce is the weakest link in the chain.  In fact, I think they are the keystone to successful project-based work.  Workforce involvement in the project management process results in accurate information and good decisions.  What are you doing to keep your project teams involved in the process?  Are you using software or something else?

One of the hardest things I faced when I was an accidental project manager (at a 3D digital content creation company) was that I didn't know how to do what the digital artists were doing. To their way of thinking, it was a case of "Those who know, do; those who don't, do project management," and "Why should we listen to you when we're the artists and you just enter stuff into some business project management software program."

I had to find a way to not only build team cohesion, but also find a way to garner their respect to insure they listened to me and worked with me, so the projects we did together were successful. In the case of this sort of project based work, failure was simply not an option—the 3D content was commissioned by a customer for use in a commercial, movie, or simulation, and it had to be ready to use on or before the due date. No excuses.

What to do? This was a completely foreign situation for me (I'm told I'm quite likeable, really). I'm fairly creative and artistic, so I tried to learn how to create digital content using a 'simple' 3D modeling program; sadly, I was really not very good at it. But in the process of trying, I did learn a lot of relevant terms and concepts that were incomprehensible to me prior to my aborted attempt to walk the walk. I could now look at a wireframe model and see an inverted polygon; I could look at a texture-mapped image and find areas of interpenetration, I could speak with them in their own geeky-3D language!

And, just like that, everything was ok. Turns out all they wanted was to know that I felt their pain, respected their work, recognized their genius, and appreciated that what they did was definitely NOT something just anyone could do. Some call it mirroring; some call it mentoring; I call it team-building.

When starting a project, it's important to first develop a rapport with your team. Everyone has a different approach to this ... some use pizza and donuts, others do team-building exercises and games, and far too many just don't bother to do anything more than fix deadlines and yell at people. Can't see this last one ever being very useful.

How do you turn your new teams into cohesive units? 

As long as organizations are flush with cash and resource rich, achieving work management success is relatively easy.  However, when budgets are tight and resources are stretched thin, the secret to successful project based work is a little more challenging.  That being said, as project teams are forced to work with smaller budgets and minimal resources, focusing on these three things will enable success:

1. The Right Projects
2. The Right Team
3. The Right Approach

The Right Projects:

Depending on the organization, there are a number of criteria for choosing the right projects, however, when resources are scarce you might want to ask the following questions:

• What will it cost to get the project done (low capital cost is most desirable)?
• Can we achieve the objective with our current resources?
• Is it possible to finish in a short time period (less than six months)?
• Is there a lot of need?
• Is it a low-risk initiative?
• Will it provide a high payback?

The above questions will help you determine if the project under consideration is the right project.

The Right Team:

Merely because someone is available doesn't mean they are the right person for the team.  Make sure you have the right skills and the right people on the team.

The Right Approach:

Depending on the project, there are many approaches; however successful projects have a few things in common regardless of the project management tools you use: an engaged project sponsor, a clear list of objectives, and a reasonable timeline.

It's not impossible to be successful with smaller budgets, all you need is the right projects, the right team, and the right approach.

The philosopher George Santayana said, "Those who cannot learn from history are doomed to repeat it."

This is sometimes referred to as Santayana's Law of Repetitive Consequences; and is nowhere more evident than in project based work.  It's been said that insanity is doing the same thing over and over again, expecting different results.  The increasing pace of change in the workplace often makes it difficult to learn from experience as processes and personnel are constantly changing.

In my opinion, to successfully learn from experience requires a regular and consistent approach that can be incorporated into any work management methodology.  Here are a few suggestions to help any project team learn from experience:

• Establish a venue for sharing lessons-learned: It doesn't matter whether you call it a post-mortem, a project review, or a project retrospective, most organizations don't do them—but they should. 
• Share what has been learned: Although most organizatios don't bother with a project retrospective, those that do don't always create an environment that encorages real learning—and even fewer share what was learned.
• Don't make learning the next corporate initiative: It's natural for organizations to try to formalize the learning process into the next corporate project.  Although the natural learning process should be encouraged, "corporate" is all to often the same as "bureaucratic," which employees will be more likely to avoid.
• Don't make learning a one-time activity: Project learning should be ongoing and interactive—don't let it become an isolated activity that happens rarely.

Every organization has different needs.  Some rely on their project software to help facilitate the learning process.  I think that's good, but even organizations that don't use any specific project management tools need to create an environment where project learning can regularly take place.  Because this is a challenge for a number of organizations, please share some of your suggestions and successes.

I think it's universally accepted that collaboration and cooperation are critical to the success of project based work.  That being said, how should organizations define cooperation success and how do they achieve it?  In an article written by Sue Dyer for Projects@Work, she suggests three levels of cooperation:

1. Cooperation
2. Collaboration
   
3. Co-Creation

"These three levels of cooperation are available to all teams," writes Dyer.  Let's talk about her five suggestions for pushing cooperation to the next level.

Tip #1: Clarifying Roles and Responsibilities

Successful cooperation depends on clearly defining what you are trying to accomplish.  It's easy to make assignments and hold each other accountable for whether or not specific tasks are completed, but cooperation can only happen if everyone understands the vision of what they are doing "together." 

Tip #2: Commit to Being Fair

The foundation of trust in any kind of strategic partnership or cooperative effort is a commitment to being fair.  Successful project management cooperation requires that team members have confidence that they will be treated fairly.  When that atmosphere exists, cooperation and synergy really begins.

Tip #3: Get Off Your Butts

Objectives might not always be easy.  If all you ever hear is, "yes, but," you're team is defeated before you've even begun.  This can make the team adversarial—the opposite of cooperative.  Take time to find out why there is push-back and work together to find a solution.  Cooperation implies working together to overcome obstacles.  Saying, "Just make it happen," doesn't just make it happen.

Tip #4: Create Accountability

Dyer recommends some kind of a scorecard for offering anonymous feedback, so team members can see where they stand with each other and on the objectives.  I prefer making expectations clear in the beginning (see Tip #1), and regularly evaluating progress against the objectives.  Of course, sometimes situations change which will require objectives to be adjusted.  Regular and productive communication and collaboration will make this a seamless process.

Tip #5: Plan For Disagreements

Regardless of your particular work management plan, nothing ever seems to go exactly as planned—and people don't always get along.  Creating a conflict resolution plan before conflicts exist makes dealing with issues among team members easier to resolve.

Creating an atmosphere of cooperation, collaboration, and co-creation doesn't just happen.  It takes some elbow grease.  I'd love to hear about successes you've experienced in this regard.

What makes someone a stakeholder, anyway? Let's see ... project sponsor; customer; investor, CEO, champion .. actually I think it really means anyone who has any stake in the project or the outcome, but for now let's focus on the sponsor/champion persona.

I was reading a discussion string on LinkedIn the other day about what factors lead to project failure, and the poster and most of the commenters agreed that the #1 factor leading to a failed project is stakeholders. This surprised me, but I guess I've been lucky in that I've never managed a project where I've had to deal with this personally. But I do see it and hear about it, so I wanted to consider it more closely.

Stakeholders seem to all start out as an avid champion of the project, regardless of their title or vantage point, but over time they tend to fall into one of three categories: friend, foe, or neutral. The friend is the easiest to work with - they have a vested interest in a successful outcome, and really want to see you and the project succeed. The neutral parties were most likely excited and invested at the beginning of the project, but have lost interest or been distracted by other things over time. 

A foe is not someone who is against your project, but it might be someone who competes with you for resources or tries to allocate them to other projects. Anyone in project management or who performs project based work will have to deal with this conflict eventually. The trick is to do your best to anticipate the situation and communicate your resources needs ... a preemptive strike, if you want to look at it as conflict resolution.

So, it all appears to come down to Stakeholder Management, which we'll leave to another post (except for this cartoon, which just amused me).

I will say that a flexible online project management tool with good reporting capabilities can go a long way to keeping stakeholders informed and so at bay. But I think the real trick is to avoid the pitfall of coming to see ALL your stakeholders as "The Enemy." It's so easy to get into an us-against-them mindset, but this is completely counter-productive.

How do you see your stakeholders? What advice do you have to offer to other project managers to keep their stakeholders all planted solidly in the 'Friends' category so they can get on with the job of project management?

You may have a stakeholder meeting scheduled for half and hour, but in reality you've only got about 60 seconds.  After that, you've got to earn their attention, or they'll start checking their email and watching the clock. 

Everyone involved in project based work has to deal with sponsors and stakeholders.  I stumbled across these 10 tips to keep stakeholders interested and engaged a couple of years ago, I think they still apply:

1. Pique their interest—An agenda is always a good idea, but a brief summary of what will be discussed gives them a take-away and allows them to come prepared with questions.
2. Don't assume they know their job as stakeholder—They might understand the high-level view, but you might need to help with the details.
3. Keep it simple—Give them the situation in straightforward terms.  Don't overwhelm them with information.  Cut to the chase.
4. Use numbers and pictures—PowerPoint is a great tool for presenting graphics and numbers to stakeholders.  It's how they present information to each other.  You should use it too.
5. Sometimes you'll have to use logic—Accept the fact that there might not always be data to support a particular situation.  Not having numbers to back up your position will make your argument problematic, so you may have to turn to "if...then..." logic to shed light on a situation.  However, don't expect the same results or response from stakeholders—numbers rule with them.
6. Waiting is never a good option—Don't wait until a problem is obvious—it's often more difficult to solve the issue at that point.
7. Always offer a solution—If you are going to bring up a problem without offering a potential solution, you might as well tell all the stakeholders, "Fire me now."  That's why you're the project manager.
8. Specify the actions required of them—If stakeholders need to take any action, don't assume it will be obvious to them.  Restate—in list form—what actions need to be taken and by whom.
9. Always say "yes," but make sure they understand the cost of "yes"—Sponsors and stakeholders don't like to be told "no," so don't do it.  Just make sure that they all understand what "yes" will cost.  That way they can judge for themselves whether or not "yes" is worth it.
10. One last tip—Don't stop reporting status just because stakeholders stop requiring it.

Regardless of your work management methodology, there are a lot of project management tools out there to help manage tasks and timelines—just make sure you also have access to the data stakeholders want to see to make decisons.

Did I miss anything?

As most of us know, working with a software customer support department can be difficult.  We often feel like the support representative doesn't understand our problem and is just there to get us off the line.  I believe this happens because we usually view the problem as something the company we're working with has done wrong and they are responsible for fixing it.  While this may be true at times, the way we approach these issues can go a long way in our ultimate ability to get the issue resolved and continue on with our work.

Here are 4 tips that will go a long way in getting what you need out of a customer support department.

Understand that all support representatives are regular people.

We often view the person on the other end of the phone (or online system) as a machine that is supposed to fix my issues.  While customer support representatives are there to help, they also respond to positive attitudes and helpful responses, just like we do in our daily jobs.  When you call customer support, understand that the way you treat them goes a long way in the way they will treat you.

Do your homework before calling.

We are often calling customer support because something either isn't working right or we just don't understand how it is supposed to work.  Educating yourself on the topic at hand and investigating possible reasons for the issue are extremely helpful to customer support representatives.  Letting the representative at the beginning of the call know exactly why you're having a certain problem and what you've done to investigate on your own will really help get that support representative on your side.  It's amazing how far a support representative is willing to go for someone who really tries to help themself first.

Listen to and follow the suggestions of the representative.

I've often caught myself calling customer support and before the representative even starts to give me some suggestions I realize I'm thinking, "This guy can't possibly know more than me.  I know what I'm doing and their system is just broken."  While this might be true for some people, following the representatives suggestions shows that you really just want to get the problem solved and aren't worried about how you or the software looks in superficial terms.  This step will really get the representative invested in helping you as a person because you have shown your willingness to be helped.

Understand that all software has bugs and limitations.

Customer support representatives are not software developers and chances are that the person you are talking to didn't actually create the software you are working with.  Every piece of software in the world has bugs and limitations and a support representative cannot change that.  Having that understanding and adhering to the points I've previously made will help you get a realistic and valuable representation of when you can expect a fix for the current issue.  Even when you are informed that you've come across a software defect, thank the representative for their time and ask for details such as "When can I expect to see a resolution of this?" or "Is there something else I can do to get my work done in the mean time?".  These types of questions, when posed with the right attitude, often generate very helpful tips and tricks from the support representative.  Berating a Representative for a software defect does not help any situation.

While I certainly understand the frustrations that can come with working with software customer support, I have learned that following this advice always helps the situation.  In the end, we all want to perform well at our jobs, and helping a customer support Representative help you is a good step to accomplishing that goal!

Yesterday we talked about some successful tactics for effectively working with project stakeholders.  I believe a productive and ongoing dialog with all the project stakeholders is critical to project success.  That being said, when stakeholders become nothing more than noisemakers they can hurt morale, hinder performance, and put projects in jeopardy.

What is a noisemaker?

A noisemaker is someone who tries to influence a project or a project's outcome to a degree that is disproportionate to their role and negatively affects project performance.  It's possible a noisemaker could be a stakeholder who is not directly involved in the project, a team member who overrides customer input on requirements, a customer who attempts to dictate technical details, or even an end user who insists his or her area of functionality receives attention at the expense of others.

That being said, not everyone who becomes involved in a project outside of their role is necessarily a "noisemaker."  Sometimes a stakeholder outside of your project can help you deal with other out-of-control stakeholders.  It all depends on whether or not their additional input has a positive effect on the project.  However, left unmanaged, noisemakers can have a disastrous effect on project based work.

How Does One Manage Noisemakers?

The first step is to recognize the problem—and this is a project-long activity.

Still, recognizing the problem doesn't solve it.  The next step is to make sure that there is an appropriate way for stakeholders to participate and offer input.  Directly soliciting opinions early sometimes helps cut noisemakers off at the pass—and helps circumvent any damage they might cause later on in the project.

There may also be times when you need to solicit help from another stakeholders to help turn a noisemaker into a team player—making them an asset to the project.  However, sometimes noisemakers actively work to prevent project success and you may need help to remove their influence in every way possible.

Managing stakeholders is an ongoing process and critical for work management success.  Successful project management requires diligence, persistence, and tact when working with stakeholders—and noisemakers.  I have yet to meet a project management professional who doesn't have to deal with noisemakers at one time or another.  I'd love to hear about what you are doing to manage those issues.

In the 15 years I have been in the software business and the over 20 years I have been implementing systems, it never ceases to amaze me at the number of implementation plans I review that I instantly know will fail.  A plan for success is simply the right balance of scope, resources and time.  Revolutionary, I know.  We've only heard that a million times before.

However, I can equate it to a story my son shared with me.  My son, Gerald, was a pole vaulter in High School, jumping 15 feet, which put him in the top 3 in the county.  A few of his track teammates would tease him about how easy pole vaulting was and anyone could do it.  So he handed the pole to one of the guys, Jeremy, who was boasting about his ability to do any track event without any coaching.  Jeremy knew it all and was athletic and he was convinced that he could vault as good as Gerald.  Jeremy took the pole and just started running down the runway and attempted to plant the pole in the box and launch himself in the air. When the pole bent, it slammed him right back down on the ground.  He never got more than a few inches off the ground and was stunned by how hard the pole flicked him back on the ground.  Jeremy returned the pole to Gerald and simply said "You the man.  That's way harder than it looks." He walked away quietly.  He became one of Gerald's greatest fans at the meets. 

So why do we approach a project implementation in the same way?  Without a good plan that has realistic goals, objectives and defined scoped, along with the right skilled resources planned along an achievable timeline, the project will fail.  Here's the secret sauce:

Success Plan = Realistic Scope + right skilled resources + achievable timeline

Defining a realistic scope should be something achievable within 30 to 60 days.  A good plan requires planning with the right people in the discussion.  Begin with the high level goals (company, annual, quarterly, etc).  Align the project to one of these goals.  Then further define the goals and objectives of the project that will directly contribute to the high level goal you tied the project to.  Define the requirements needed to achieve the goals and objectives.  Simple and small is always the way to get to a full scale implementation.  Phase the scope into short time cycles (30 to 60 days) so that achievements are delivered as value to the business on an on-going basis.  If you start simple, you can always add additional capabilities or complexity.

The next step is to evaluate the resources needed to deliver the requirements.  This must be the right resource not just anyone who is available.  Make sure the resources defined for the delivery of the project really do have the right skill set to deliver on the requirements.  If the resource skillset required doesn't exist in house, then look to outsource or bring in the skills needed.  There are many reasonably priced outside resources that can be used to deliver on key elements of a project if managed properly.  When defining the resource pool, make sure to use available work days for those resources (take out PTO and training courses).  Then evaluate what other tasks or projects they are assigned to and determine capacity for realistic available dates of the resources.

The next step is to review the timeline.  Just like a good forecast, it is best to create your preliminary project plan with the main elements required to deliver, following a proven methodology of stages (i.e. plan, design, build, test, deploy) and see what it is going to look like.  Apply the resources you have identified with the available capacity you have defined.  This should give you a preliminary timeline of delivery.

Finally, once you have a preliminary plan that has the scope defined, the right resources assigned that produces a first draft of the timeline, review this plan from a realistic approach.  Analyze eachs stage of the plan and ask questions (i.e. The plan shows it will take 2 weeks to install and setup the solution, does that make sense if you know it takes only a day to do this? or if the plan shows it will take 6 months to complete, can you review your requirements and move some planned deliverables to the next phase?)  Don't be afraid to change your scope right up front.  If the plan seems like it is too heavy and complex to deliver in a 30 to 60 day cycle, cut the scope to something more reasonable and attainable.  Find the number one or two pain points that can make a difference in the group or organization quickly and focus on delivering that one element.

Make the plan simple, concise and achievable in 30 to 60 days or less.  Anything more will fall into the 75% of projects fail bucket.  I am a believer in 100% of projects can succeed with a realistic plan defined with the right scope, resources and timeline.  Look for more indepth discussions on each of these secret sauce elements in the near term.

A good caddie is a critical component to a successful tournament for a golfer.  On the golf course, a caddie has a number of basic responsibilities:

• Ensure that the proper number of clubs are in the bag
• Help in the selection of clubs for specific shots
• Let the golfer know where pin placements are for each hole on the golf course
• Alert the golfer to where a good spot to hit their shots would be, and if they miss, where to miss
• Help read putts if needed

A great caddie will have walked the course and knows everything there is to know about the softness of the turf, the condition of the sand traps, and has personally paced off the yardage for each hole.  This information allows the caddie to provide the information the golfer will need to play the best round of golf possible.

Throughout the course of a project, it's often the tough decisions made by stakeholders that make the difference between a successful project and one that fails.  Sometimes the importance of stakeholders in the success of project based work is overlooked.  However, it's vital to keep them informed with the most timely and reliable information possible.  Regardless of  the project management software you employ or your particular work management methodology, here are three keys I've discovered to encourage successful stakeholder involvement:

1. Ensure that stakeholders, sponsors, change agents, and champions, are involved and in agreement throughout the project.
2. Guide the decision-makers through the key steps to success and make sure they are applied consistently throughout the project.
3. Keep stakeholder's decision-making efforts based on the best practice areas that have helped other projects deliver successfully to achieve the desired results.

Not unlike the relationship between a professional golfer and caddie, the biggest benefit to keeping stakeholders in the loop is an increase in stakeholder collaboration and a more successfully portfolio of projects.

How do you keep stakeholders engaged in your projects?  Do you have any suggestions that I may have left out?

We all spend a lot of time talking about how critical it is in the project and portfolio management arena to communicate. About how to promote communication throughout the organization when doing project based work, and how we will get enough information out of our teams to report up to the stakeholders and satisfy their needs. But do we spend enough time planning exactly what should be discussed, beyond the "I did this," You do that," and "When will this be done?" questions/answers? I think we sometimes miss the real meaning of collaboration. It's much more than a simple status update once a day/week. Your team is actively working on projects, and it's a good bet they have some truly valuable feedback—isn't it worth a bit of your time to listen to them?

As we all know, a team leader has a lot on his/her plate, not the least of which includes boosting individual team member productivity, team effectiveness, and overall organizational success. You've already seen to it that your team is comprised of all the right people, with the right skills, knowledge, and motivation; a focused group of pros that have a clear understanding of the deadlines, milestones, and expectations relative to the project. So, take advantage of all those wonderful minds.

Set a monthly team meeting that has nothing to do with milestones or deadlines, and everything to do with teaming and sharing ideas. Then open the floor to feedback. You can go into the meeting letting everyone know that any thoughts or suggestions that all agree have merit will be brought to the attention of the stakeholders, without offering any guarantees. This at least gives your people the opportunity to be heard. This alone should increase team cohesion, motivation, and productivity. Feeling like part of the project, and not just a cog in the project works, helps everyone feel like they have more of a vested interest in a successful outcome.

It becomes a win:win:win situation - your team is happier, management likes the camaraderie and output, and your job is just a bit easier.

Do you encourage your team members to offer their thoughts and feedback? How has it worked for you?

To pay homage to all our friends in New York, Washington D.C., Chicago, and other points East buried in the snow, I thought I would share a personal "snow" story.  Growing up in the Rocky Mountain West, I have lived with snow my entire life.  For example one night a couple of years ago, a freak snow storm turned my normal 35-40 minute commute home into a five plus hour ordeal (but that's another story).

As a seven- or eight-year-old I remember one snowy day when, for some reason I can't remember, I was all dressed up in my Sunday best just sitting at home when my best friend Scotty dropped by to see if I could play.  We wanted to venture out into the neighborhood and enjoy the beautiful snowy day—despite my polished dress shoes and the fact that my mother had told me not to go outside that day.

Rules are made to be broken, right?

We determined that the reason my mom didn't want me outside was because she didn't want me to get my shoes wet—so we devised a plan.  Scotty would take a trashcan lid and push the snow down in front of me so I could step in the mashed-down snow (keeping my shoes dry).  We went all over the neighborhood like this.  Until my mom found us.  I still don't remember why I wasn't supposed to go out, but she did try to impress on me that rules were NOT made to be broken.

A couple of years ago I stumbled across some rules that Mark Lilly and Tim Rahshulte had put together for Gantthead and called "Unbreakable" for everyone doing project based work.  Lily and Rahsulte ask, "Why do so few projects succeed?  Despite the decades of increasingly complex attempts to manage projects, far too many managers overlook the 10 Unbreakable rules for project success...these common sense guidelines hold the key to increasing your success rate and delivering greater consistency across your projects life-cycle."

Here are their 10 "unbreakable" project management rules:

1. Know what you are doing
2. Know why you are doing it
   
3. Be prudent, honest, and prepared
   
4. Play to your strengths
   
5. Know how to navigate
   
6. Know how to communicate
   
7. Know how to succeed
   
8. Know how to fail
   
9. Know when the project is over
   
10. Know how to learn

I've heard it said that "it's easier to get forgiveness than permission," but when considering successful work management methodologies, I think I agree with Lilly and Rahschulte.  How about you?  Are there any rules you think we should add?

After 1908, things would never be the same.

At the beginning of the 20th century, automobiles were expensive, complicated, hand-made machines that were unaffordable to the average American.  Henry Ford didn't invent the automobile, but he was determined to build something simple, reliable, and affordable—something the average American worker could buy.  The result of this goal were two significant innovations—the Model T and the assembly line.

The original price of a the Model T was $825, selling over 10,000 cars the first year.  Four years later, Ford was able to drop the price to $575, giving his Model T 48% of the market by 1914.

Describing the assembly line, Charles Sorensen, a major contributor to the development of the process, wrote, "What was worked out at Ford was the practice of moving the work from one worker to another until it became a complete unit, then arranging the flow of these units at the right time and the right place to a moving final assembly line from which came the finished product.  Regardless of earlier uses of some of these principles, the direct line of succession of mass production and its intensification into automation stems directly from what we worked out at Ford Motor Company between 1908 and 1013..."

I think the genius of the early team at Ford was recognizing that the successful, and cost effective, manufacture of an automobile was the culmination of a sequential process.  A number of work management best practices probably have roots in the Model T and Ford's assembly line.

Similar to putting the pieces of an automobile together in an assembly line, successfully managing project based work is more than just planning and executing tasks.  It involves the entire project life-cycle.  From idea submission to the completed project.  Although project managers might not have direct impact on every step in the process, I believe they are the crux, or keystone, upon which the success or failure of any project depends.

Project management tools or methodology that only address part of the process are akin to building a really nice seat or chassis, without the rest of the car.  In my opinion, the following four critical steps in the project life-cycle need to be addressed by any work management process:

1. Initiation: This is where we ask the question, "What do we want to do?  Does it make sense to do it?" This requires some kind of request queue, a means to evaluate the merits of a potential project, along with a way to determine if there is adequate capacity to actually accomplish it.
2. Planning: We need to ask, "How are we going to do it? Who is going to do it? How much will it cost and how long will it take?" Project managers play a big role here—creating project plans, identifying and assigning resources, and managing project expenses.
3. Execution and Controlling: This is where the rubber hits the road.  "Are we doing what we agreed to do?  Are we doing it right?" Here's where project managers probably spend the lion's share of their day—managing time, costs, change, team performance, risk, issue, acceptance, and communications.
4. Closure: This is where we ask, "Did we accomplish what we wanted?  Can we do it better next time?" Tools and methodology should support a robust way to evaluate lessons learned, facilitate post mortem, and initiate project improvement.

I seldom think about the assembly line when I climb into my car for the drive to work each day.  But, I am glad that everyone on the assembly line was there when my car went through. 

Does your project management process address the complete project life-cycle?  Have I left anything out?

One of my favorite Verizon ads depicts a couple of young teenagers and their parents talking about their new web-enabled cell phones.  The conversation goes something like this:

"I'm sitting on the porch," Tweets Dad.

"Cool it with the Twitter updates Dad," says the son.

"Mom, you don't need to write I love you, I love you, I love you on my wall all the time," bemoans the daughter.

The discussion continues with the son and daughter chastising their parents about spending too much time on the Internet with their cell phones ... Dad tweets, "I'm still on the porch."

Fortunately, social media offers a lot more to project management professionals.  In fact, I'm convinced it can play a vital role in building up project management knowledge in many organizations.  Cindi has talked about this before.  A couple of months ago, in a post she titled, Project Management and Social Media—What's the Connection?, she spoke generally about how social media allows people to connect and form personal and business relationships with some incredibly smart and talented professionals. 

"Post a question on Linkedin and see how many thought-leaders give up their time and expertise!" she said.  "Or Tweet out a request for ideas about a dilemma you're having with a project or that you need ideas for a PPM software.  Answers will come flying back to you."

I agree.  In my opinion social media, at least for all of us engaged in any kind of work management, provides a a wealth of experiential-based knowledge that can be successfully applied by anyone looking for a better way to get work done.  I believe this type of knowledge-sharing is important as more and more organizations look to project management best practices to increase efficiency in the workplace.

In David Wirick's book, The Project Management Imperative: Mastering the Key Survival Skill for the 21st Century, he writes, "The establishment of communities of practice can help sustain knowledge gains and spread a culture of project management learning."

He may not have been thinking about social media, but social media does provide a "community of practice" that is freely available for the asking—and can positively impact the way we learn.  Wirick suggests that effective learning requires both explicit and tacit mechanisms for transferring knowledge:

1. Explicit Knowledge: Is transmitted in formal, systematic language.  It's what we learn in training programs, manuals, and by reading books.
2. Tacit Learning: Is personal, context-specific, and hard to formalize and communicate.  In most cases it requires face-to-face interaction and is very dependent on the context where the knowledge will be applied.  I believe social media provides an opportunity for an additional mechanism for tacit learning.

"Explicit knowledge transfer mechanisms include newsletters, presentations, status reports, project documentation, training programs, job descriptions, manuals, and the application of standardized processes and tools," writes Wirick.  "Most managers are adept at explicit knowledge transfer; it is typically one-way communication from senior levels to lower levels of the organization."

Unfortunately, there are some things you just can't learn from reading a book.

Some things require the framework of experience, collaboration, and the time for learning to evolve.  This type of knowledge is best obtained by exposure to working project managers—and is the important role I believe social media can play in project and portfolio management.  Combined with mentoring, workshops, and social events, social media provides another excellent way to foster communities of practice.  "Tacit knowledge transfer requires informal contact and a willingness to share information," suggests Wirick.  All of which can be found in social media.

Oh, I'm still sitting on the porch.

Last week Ty Kiisel posted a blog about pulling the plug on a good project gone bad. It got me thinking about a project a former employer initiated a few years ago. I was brought in late in the game and asked to review it from the sidelines, as my director suspected the project was going badly, the vendor was off track, and the company was wasting money.

I reviewed the project and found a number of issues that needed to be addressed, but as is typical in the case when project management is spread out over too many people or non-existent, I heard excuses and a reminder that I was not the PM. So I contributed content when asked to do so, watched the work "progress," and wondered at what dollar amount someone would cry uncle. It actually took another year and about a million dollars to get to that point; a shame really - it was a very good idea, just executed very poorly.

The point here is that this project went way over budget and way off schedule because of one thing. Ego. The CEO. who gave the thing the thumbs-up in the first place, was simply not willing to see or admit that it was just not working. Don't get me wrong, I'm not saying to just give up whenever things get difficult. I'm just saying there is a point when you're throwing good money after bad and it's time to review your options.

As Ty mentioned in his post, all project based work should have a solid start-to-finish plan; and that plan should include an exit strategy in case things just don't work out. Also, it is never a good idea for a company to hire an outside vendor and then not assign project management oversight to an internal person. In this case, the vendor answered only to CEO, and neither he nor the SVP of Marketing were willing to admit a mistake had been made and the project was a failure; it was only after both were let go that the project was abandoned.

Have you experienced anything like this? How far have you seen an ailing project go before someone recognizes a problem exists and is willing to pull the plug?

The world is becoming smaller for corporations with engineering, product development, and manufacturing often located in different parts of the world.  Cultural differences, language, geography, and time are all factors that must be considered if project stakeholders are to have a realistic expectation of the additional time and effort required when working with globally diverse project teams.

Staying Up Late or Getting Up Early—Share the Pain

Working with teams in different timezones can sometimes be challenging when you need to get the whole team together.  Particularly if we're talking about a time difference of 10 or more hours.  For example, as I write this at 7:45 am local time, it's 11:45 pm in Tokyo, 2:45 pm in London, 12:45 pm in Rio, and 10:45 pm in Beijing.  The challenges of putting together a project team meeting with a globally diverse workforce sometimes are as basic as determining what time to hold the meeting.

Nobody on the project team should be asked to regularly stay up until 2:00 am just to make it more convenient for you.  Everyone on the project team should be able to share the burden of an inconvenient meeting time once in a while.  A simple solution is to try to hold team meetings when everyone is at work, which might be early in the workday where you are and later in the workday where part of the team is located—at least everyone should take turns meeting at inconvenient times.  (Here is where my mother would remind me about the Golden Rule and doing unto others as we would have them do unto us.)

Do You Have Frequent-Flyer Miles?

Sometimes you'll just have to bite the bullet and bring the team together.  We have global teams at @task, and although we don't get everyone together often, we do get together.  On-demand project management software is an option that helps many of our customers collaborate and work together in different countries, timezones, and languages—but they still pull the teams together from time to time.

In Philip Crosby's book, Quality is Still Free: Making Quality Certain in Uncertain Times, he says, "Quality is free.  It's not a gift, but it's free.  What costs more than money are the unquality things—all the actions that involve not doing the jobs right the first time."  Some of the money saved by working with global teams will need to be invested in enabling those teams to work well together—and sometimes that requires some time to physically be together.

If you're working with global project teams, make sure you enroll in a frequent-flyer plan.

Sprechen Sie Deutsches?

The nuances of different languages beg for miss-communication.  Even where your particular language is spoken as a second language, it's critical that communication be clear.  We need to be cautious, particularly where the lion's share of communication is done via email, where body language and facial expression are not available to aid understanding.  Video conferencing is a good option, but at the very least, make sure emails contain all the information necessary to communicate your ideas clearly.  I try to address all my emails with a salutation and a name to remind me that I am actually communicating with a real person.  Even amongst my co-workers, where English is our native language, we sometimes misunderstand and misinterpret an abrupt email.

Cultural Differences

If part of what defines a culture is our shared experiences, taking time for global team members to become better acquainted—and share experiences to create a team culture is important.  This is true even if your team only spreads across the United States.  Take the time for global teams to become familiar with their varied customs and cultures. 

Managing project based work with global project teams might be a little more complicated, but keeping expectations realistic among team members and stakeholders can lead to success.

Sporting goods manufacturer and distributor Rawlings works with project teams around the world, click HERE to learn about what they're doing to make their teams successful.

When Italian engineer Bonanno Pisano began construction on the the Tower of Pisa in 1173 I'm sure he wasn't expecting it to start tilting—before the third story was finished.  The best guess as to why the tower started to lean was that Pisano underestimated the weight of the 185-foot tower on the stone foundation of only ten feet.  The weak foundation combined with the soft sand, rubble, and clay underneath the almost 16,000-ton tower contributed to the uneven settling of the white marble tower.

Although the builders tried to compensate for the lean, by the time the tower was completed in 1350 it was leaning a full 4 feet, 7 inches from vertical.  What's more, by the late 20th century, the tower was leaning a full 17 feet.  (The tower has since undergone an intensive restoration project to keep the tower from failing completely.)

Whether you are building a 12th century bell tower or starting a new project, a firm foundation can help you achieve project success.  The following are three suggestions for building a solid foundation for your next project:

1. Make sure the project has a clearly defined business objective—and that everyone has a clear understanding of what it is.  It's important for stakeholders and project teams to understand the business value of what they're doing.  Keeping the project vision visible and accessible enables everyone involved in the project to stay focused on what's important—and helps keep scope creep to a minimum.
2. Make sure the project has executive commitment to see it through.  One of the quickest ways to kill a project is to pull its funding out from under it.  A committed executive can also help promote the merits of the project to others within the organization to build a broader base of stakeholder support.
3. Make sure there is a shared sense of determination to finish the project.  If the only member of the team committed to finish the project is the project manager, it's not likely the project will ever be completed.  Individual team members and executive stakeholders need to have the same determination.  Without a shared sense of determination to finish, projects languish and eventually fail.

Although the Leaning Tower of Pisa is one of the most recognizable buildings in the world, it is not a good representation of a successful building project.  I'm sure if Pisano had it to do again, he would have spent more time on the foundation and built a tower that stood straight.

Business project management software offers both experienced and inexperienced project managers a number of valuable tools to help them establish work management best practices and methodologies.  That being said, nothing can substitute for establishing a good project management foundation—or as my grandfather used to say, "Well begun is half done."

As a 12- or 13-year-old Boy Scout (many moons ago), I was on a fishing trip with my troop in a wilderness region of the Uintah mountains of Utah.  Our goal was to fish the isolated high-mountain lakes for fresh rainbow trout.  At the time, my father had a very nice four-piece fishing pole that I "knew" would be perfect for the trip, so I "borrowed" it.  We had a great time.  Until the morning I cast out into the lake and the two end pieces of my "dad's" pole shot off after my bobber and the bait.

The weight of the pole took the line right to the bottom, where it snagged.  No matter what I did, I couldn't free the line.  Normally, I would have jerked it free and just left the hook at the bottom—but it was my dad's pole, and I wanted to save it instead of explain why I only brought home half of it.  Panicked, I stripped down and jumped into the icy-cold water of the lake and tried to follow the line to where the snag was.  Within a few seconds, the freezing, snow-fed lake water took my breath and I started to struggle.

When my Scoutmaster noticed what I was doing he sharply told me to turn around and waded in after me.  He picked me up, blue and shivering, carried me back to camp and built the bonfire of all bonfires to warm me up.  Looking back, I'm sure he saved me from what could have been a disaster. 

Successfully managing project based work sometimes requires that project managers recognize when good projects have gone bad and possess the courage to "cut bait" before too many resources are needlessly put in jeopardy.  Jumping into the lake, hundreds of miles from a hospital, is a risk I probably wouldn't take again—and probably wouldn't have been encouraged by my Scoutmaster either.

Regardless of your particular work management methodology, project management best practice suggests that the criteria for pulling the plug on a DOA project should be determined prior to the project beginning.  What's more, the "firing squad" should be identified before the project begins too.  Sometimes in the heat of battle, it's difficult to dispassionately consider discontinuing a project in trouble.

I didn't want to explain to my Dad what happened to his fishing pole—but continuing down the path I was on lead to nowhere but disaster.  Mustering the courage to discontinue a project that has nowhere to go is difficult, but profitable portfolio management requires that we sometimes make hard decisions before we end up frozen and blue at the bottom of a nameless lake. 

Over the past few days, I've been writing about some of the characteristics that make a great project manager.  I don't think anyone disagrees that delivering projects on-time, on budget, and on spec are important.  I certainly think they are.  That being said, I was thumbing through some old notes last night and found these six leadership attributes.  I'm not sure where I stumbled across them originally, but they are leadership skills that can take a good project manager and make them great.

As companies turn to project based work to help make and keep their organizations competitive and profitable, the need for skilled project leaders will continue to increase.  Regardless of your particular work management methodology or business project management software, do you take time to foster the following skills or attributes?

• The gift of foresight.  I'm not suggesting that membership in the Psychic Friends Network is required, but being able to look down the road and make some reasonable predictions based upon practical assumptions is an important skill.
• Organization.  I don't think this needs much explanation.  Keeping information, schedules, and team members organized is critical.  Fortunately, most project managers I know are very organized and detail-oriented people.
• The ability to lead.  Although there are some people who are natural leaders, basic leadership skills can be learned, practiced, and improved.  You might not read about it in the PMBOK, but there are mentors, leadership training, and books you can read if an honest evaluation of your leadership skills finds you lacking.  Leadership and people skills are, at the very least, as important as methodology and tracking tools.
• Exceptional communication skills. It's important to be able to communicate with everyone involved in the project from peers, to team members, and stakeholders.  Everyone needs different information couched in different terms.  This is a skill that is vital to a project manager's success.  Adam Michaelson is talking about project communication in his blog today, if you'd like to read a little more.
• Pragmatism.  A pragmatic approach to problem-solving is a skill that is essential for a discipline that faces the regular adjustments and changes that face project managers.
• Empathy.  In order to lead people, you need to understand them and what motivates them.  Everyone is different and a one-size-fits-all approach to leadership is seldom the most successful approach.  I'm not suggesting that project managers need to get all "touchie-feelie" and start tearing up in romantic comedies (not that there's anything wrong with that), but the old saw about "..walking in another man's shoes," might apply here.

It's not a secret that in my humble opinion, like any good leader, great project managers understand that successfully leading people is half the battle to successfully managing a project.

I've appreciated all the dialog on this topic over the past few days.  Please feel free to share some of your favorite leadership skills.