A Case for Lean Project Management

lean-scatter-480x240

Have you ever heard the phrase, “Death by paperwork,” or “Death by process?” Better yet, have you ever experienced either of these? If you have worked for any reasonable amount of time,  chances are that you have. In this day of red tape  and CYA, paperwork and processes have become the norm and they can really kill your project delivery date. It isn’t always enough to simply schedule  time to complete these tasks. How about you look deep into these processes and determine their actual value and eliminate the ones that may be somewhat superfluous? After all, at some point, the work has to actually get done – and I’m sure you have plenty of it!

For those of you running a PMO with strict process guidance, please hear me out, but give me your thoughts at the end.

Here are a few items to consider: 

  1. Define the project type. It is important to understand what is truly required to complete your project. Software development projects differ greatly from a BYOD initiative or an infrastructure refresh project. Differences may include architecture reviews or design documents that would be appropriate for one project but not another.
  2. Consider the actual size of the project. There are several attributes that must be considered here including number of end-users impacted to size of project team and of course,  project budget and duration. A small project that impacts 100 users and lasts 3 months with a cost of $25,000 should have different document requirements than a multi-million dollar software implementation that takes two years.
  3. Determine actual requirements of the group you are working with. Business facing projects will typically have fewer process requirements than a typical IT project. At the same time, some business entities such as accounting or audit, may require additional processes. If the project doesn’t warrant a process for SOX compliance, for example, why even create a document for it?
  4. Simplify some of the documentation that you will use for every project. Project charters, for example, have a full gamut of length and complexity. In reality, the project charter really should be a simple document that gives a brief description of the project as well as a list of the high level roles and responsibilities that the PM would be accountable for. Anything else really belongs in other standard documentation.
  5. Make some documents standard. Think about a communication plan for a moment. What is defined in the communication plan? Types of communication with definitions of each as well as expectations that each project will have regarding all types of communications. When you think about it, most of these types of communications are the same across every single project. Team status meetings, stakeholder meetings, leadership meetings, status reports, RFPs, etc. will be the same. Sure there is some customization for each one based on the team and requirements, but create a well defined template that irons out each type and basic expectations. Don’t re-write every document every time.

It is time for the project bureaucracy to start swinging the pendulum the other direction a bit. It is possible and smart to cut out some of the formalities for some projects. If it is required, don’t cut it out, but make it a requirement if it has no value. Documents with little to no value that get created are simply expensive time wasters. Resist the urge to require a check box for every little thing. Here are some high level suggestions

Need to define but don’t go overboard:

  • Charter – keep it simple
  • Scope – sometimes a high or medium level scope statement is all you need. Detailed scope statements get very complex and can cause you to get lost in the weeds
  • Schedule – build your schedule so that it is manageable. You don’t need every little detail documented in the schedule. If you aren’t careful, you will spend all of your day trying to keep up with the schedule updates and changes.
  • Status reports – here everyone rolls their eyes. Often times status reports aren’t even read. Keep these simple – and automate some metrics for easy reporting. Hint: use the Unique Task ID in MS Project to export into MS Excel for simple, automated updates. You can also create categories in your financials to report high level metrics as well.

Make some plans standard

  • Communication Plan – meetings are meetings – set expectations here for all projects and stick to it. Remember, sometimes a phone call can take the place of a meeting – meetings are expensive. If you don’t believe me … do the math yourself. I find it very interesting that certain level of employees have limits on the amount of money they can approve on an expenditure but anyone can call a meeting. If you are holding a leadership meeting that runs an hour . . . it can cost thousands of dollars just to have everyone paying attention to you.
  • Change Control – Change processes are important, but are also the same for all projects in an organization. One document for every project will suffice. Simply reference that document in your project management plan
  • Risk and Issue Logs – make a SIMPLE template and follow it for every project. This also helps leadership to see the same type of information across all projects.

Of course, there is much more that can be put here, but I’ll keep it simple myself and wrap this post up. Remember, sometimes, less is more. If you are mired in process, your project is slowly slipping away, or your life outside the office is. Either way, you don’t want that to happen.

Lead lean! Lead smart! Lead on!!

Have a great rest of your day!

I value your opinion and would love to hear from you. What do you think about lean project management? Please comment below.

Project Management vs. Project Leadership

Project Leadership vs. Project Management

Being a project manager has been a very rewarding experience for me over the last 15+ years. Whether practicing the science of project management, learning about it, writing about it or talking/tweeting about it, I have truly enjoyed almost every aspect of it.

I see a transformation coming, however, and no, I’m not talking about Agile vs. Waterfall or the newest release of the PMBoK. The transformation I am witnessing is a movement to project leadership.

The science of managing projects is fairly straight forward.  No, I did not say easy, with good reason. Project management requires a specific set of skills and talents to take a project from conception to close within a specific timeframe and budget. Practicing the art project leadership, however, goes much deeper, into the realm of relationships. If you dig in and form solid, working relationships with your team, you will allow them to be rewarded as much as you are.

Consider these attributes:

  • Give all the credit: It is critical to remember that you are the project leader, not the team. Your team is who is doing the work. Your team has the expertise. Give them high praises when they do well. Praise individuals, praise small groups, and praise the entire team, and praise publicly.
  • Take the blame: Troubles are going to happen; it is a given when it comes to projects – regardless of what they are. Budgetary items will come in higher than expected, delays in the schedule are going to occur, and quality may come in sub-par. Don’t throw Bill under the bus for that typo in the code, or Jack for misunderstanding the requirements, or Sally, who forgot to get a quote on a critical piece of infrastructure. When reporting, state the facts – but leave names out of it. When asked, put yourself in as a shield between management and the team. By doing so, you will build and environment of trust, not only with your team, but with management as well.

Don’t get me wrong; if a correction needs to be made, don’t wast the opportunity for a teachable moment.

  • Equip Them: Your team already has a tough job. Each team member was brought in because they have a specific skill-set that is necessary to fulfill the requirements. As a project leader, you need to do everything you can to make sure the team has the tools they need in order to fulfill their duties. We’ve all heard the phrase “the right tool for the right job.” That saying goes beyond building a house or working on a car. Having the proper software, adequate hardware, the right saws, a working micrometer, is all critical to the success of any team. If you fight for your team to make sure they have what they need, they will perform well; not only because they have the proper tools, but because they want to! Even if you can’t get everything they need, they will work harder for you because they know you are on their side.

This is only scratching the surface. What other qualities do you think would be great project leadership traits?

This post was originally posted to my LinkedIn Pulse page. It has been modified and updated for this site.

Why Building Relationships First is so Important

I was scrolling though my Twitter feed the other day when I ran across this post form PMI Mile Hi Chapter (@PMIMileHi)

Sometimes we neglect our most priceless asset — the project team. We focus too much on a project’s deliverables, timeline… #PM #PMP

This struck a chord with me. I was immediately compelled to quote it with this addition:

#PutPeopleFirst and watch the project succeed! #Leadership #PMOT #PMP

We see and hear things like this all the time, but why does this really matter? What is it about relationships that can make or break a project team? After all, these are professionals that have been hired to do a job, right? Well, the answer to that is, yes, but only for a time. If you don’t take the time to build the relationships with your team, they will find someone else, somewhere else, who will.

You see, we all have the desire to be appreciated, understood, and maybe even liked. What we don’t want is to be bossed around, micromanaged, and looked down on. As a project leader, or any leader for that matter, you have an opportunity to create a good working relationship with your team. If you do that, you will NOT be disappointed.

What do you do? How do you get there?

  • Make your open door policy is truly open door
  • Talk to your team – often – and in their environment
  • Plan team building outings – even low budget outings make a big difference
  • Introduce a little fun in the office every now and then
  • Show your appreciation when the team performs well – again, even low budget appreciation awards work

What you can expect

  • Even a team with low morale initially will start to transform
  • Attitudes will improve
  • Project performance will increase
  • Your team will become coachable
  • Your team will work harder than they ever have and will accomplish more than they thought was possible

What are some ways that you can show your team your appreciation? How do you relate to them? Please share some of your thoughts and success stories below.

Giving Your Contractor Goals: Why it’s a good idea

I have been in contract positions many times in my career and have been around even more. There has always been one thing consistent with all of those positions: contractors are never given goals. Why is that? Aren’t they part of the team? Now, I realize that there may be some HR or legal implications to treating a contract employee like a full-time employee, but there are great reasons to give them goals

Now, let’s define contractor for just a moment as there are several different types that could be considered. The notion of giving goals to contractors does not fit all contract types.

  • Consultant: This type of contractor is typically an expert in his field. It wouldn’t be appropriate to set a goal for this type of contract employee. In fact, consultants may be helping YOU set YOUR goals
  • Part-time / Short-term contractor: This contractor is usually an emergency fill-in intended to cover for an employee that may be out on extended leave or for a position that simply cannot have an empty spot. It would not be appropriate to give goals to someone who isn’t going to be here long enough to even write the goal down
  • Long-term, staff augmentation contractor: NOW we’re talking! This type of contractor is fully engrossed in your team. This person will be on your team for long periods of time, typically 3 to 6 to 12 months at a time or longer. This person will be in your data, in your systems, and in your meetings daily – and having an impact on the team, whether positively or negatively.

Here are a few reasons why it is a good idea to give your long-term contract employee goals:

  1. Ensures they are always on the same page with the rest of the team

If they are doing their job while marching to the beat of a different drummer, your “band” may get confused. When that happens, your team can fall apart and your full-time, permanent team members may start to wonder why that contract employee isn’t playing well with others.

  1. Gives them something to work towards

Believe it or not, long-term contract employees want to work on the same goals as the team. Giving them the team goals that have been set gives them a target to shoot for. In addition to the team goals, personal goals helps them to grow. Goals can give the contract employee a reason to stop and analyze his or her work to verify that it meets standards . . . or beats them! In addition, having leadership work with them on individual goals helps develop the contractor even further which is a benefit for everyone.

  1. Helps the team to get better

As you bring the contractor in closer to your team, you will start to see something amazing happen; they will actually become PART of the team and start striving to help everyone succeed.

Leaders can do themselves, their teams, and their contract employees a favor by treating everyone the same. Respect, discipline, and trust will all surface when you lead everyone towards the same common goal. Leaving the contract employees out draws a line between them and the permanent team members. This causes a disconnect and will slow the progress you are trying to make in developing your team.

Although you cannot “treat” contractors like employees with regard to some benefits and perks, you can continue to develop them. Developing your team members is an essential part of what leaders do. I would say it is the most essential part. Don’t leave out your contract personnel, they are on your team too.

What do you do to help develop your contractors?

After the Implosion: Leading your team out of the ashes

As a project leader, you have, undoubtedly, run in to issues with a project that will raise eyebrows in a negative way. You might have even experienced an implosion like I mentioned a couple of posts ago. What do you do now? What do you do AFTER the implosion may just define who you are in the eyes of your team.

In my years of experience, I have seen the good, the bad, and the truly unforgettably ugly that comes with the different types of responses. Some make me clap and shout, some make me sad and shake my head. Others, however, make me angry with a “how dare you” type of reaction. Sure, there are countless styles and things to say, but here are some types of  responses that will help your team look up to you, trust you, and even follow you. If you were my leader and you said any of these to me? I would stand up and shout “WELL DONE, LET’S GO!!”

  1. “I take responsibility.” Here are three words that will immediately take the pressure off of your team and allow them to regroup. Letting them know that you aren’t going to hang the team out to dry is very settling. Even if you were not the cause of the implosion, as the project leader and “face of the project,” you are ultimately responsible so step up to the plate. Of course, if there are personnel issues that need to be addressed, take care of them quickly, but do so privately.
  2. “How can I help?” One thing I always tell my teams is that I am here to place an “umbrella of protection” over them. That means that I try to shield them from outside distractions that can derail a team. If I need to do a better job, then I want to know from the team. Of course, if the team needs anything else, I want to know that too! As a leader, I am simply here to help my team succeed; it isn’t about me. I will even bring them coffee if they need a little pick-me-up!
  3. “We can fix this.” Telling your team that we can fix it gives them the confidence to know that you feel confident in them to be able to steer the ship back into the right direction. It will empower them to dust off their pants and get going.
  4. “Let’s make this thing work, TOGETHER!” Wow, six simple words with enough impact to elicit change like you’ve never seen. I know in my past, I never experienced these words and never felt like I had management’s backing. I was always left to my own devices to figure things out. Always out on an island with nothing more than a stick to draw a plan in the sand. Don’t leave your team to fix things on their own. You have the experience to help them. They look to you to help pick them up. Remember, the project that imploded was a team failure, not THEIR failure. Roll up your sleeves and get in there. You won’t regret it, and they won’t forget it.

These may seem simple, or even common sense, but remember, common sense ain’t so common. If you do any of these, your team will follow you to the ends of the earth!

Happy leading!!

What are some ideas you have for getting your team to dust themselves off? I’d love to hear them.

Navigating Traffic: How your daily commute can help you solve problems

What does your daily drive to and from work look like? Is it very far? How long does it take? Do you go the same route every day?

I ask these questions, because I had an epiphany the other day as I was driving home. The distance was only a few miles, but sometimes, it could take me 30-45 minutes to go those few miles. I was navigating my way through traffic when I noticed that I was making the same adjustments every single time I drove. Those adjustments were saving me time. I knew, when traffic started to back up, that if I switched lanes, I would keep moving forward, even if at a slow pace. I also knew, that if I actually exited the highway and tried to go the back roads, it would take me longer. As I pondered, this epiphany, I started to pay closer attention to my route. I noticed if I made a few additional adjustments, I could save even more time. I was managing a problem to navigate in such a way that I could have the best possible outcome.

Problem management in the office is a lot like navigating rush hour traffic. If you take the time to really think about the issues, you can navigate the problem more smoothly, and efficiently. At the same time, you can work to avoid the knee-jerk reactions that so many people are plagued by. Think o f exiting the highway to avoid the traffic jam only to be plagued by stop lights and the other drivers who thought the same way you did. Swift can have it’s advantages, but only in the short term and only if done smartly. If you take the time to really solve the issue, then that resolution can have long lasting effects. Pay attention to what is going on around you. What are some trends you are seeing, good OR bad? Take the time to think about what little adjustments you can make in your behavior or your team’s behavior to make a positive impact.

I had a problem in that I wanted to spend more time with my family. My kids are only going to be this age a little while and I want to give them as much time as I can. I estimate I saved over 40 hours a year by putting a little extra thought into my route. That is more time with my family … and less time getting upset at the long line of cars that are not paying attention. That, of course, is another topic on its own. Wow, it looks like I solved two problems . . . see what I mean?!?!

What do you think? How do you navigate problems at work or with your projects? Do knee-jerk reactions hurt you organization?

When Your Project Implodes, 10 steps to sift through the ashes

You just got out of your stakeholder’s office. Most of your tail has been chewed off and the rest is tucked squarely between your legs ….. now what? It is time to let your leadership shine through! Use these steps to pull your project out of the ashes and make things right.

1. If you didn’t take notes during the meeting, go back to your office and write down everything including the good, the bad and the ugly. This will help you to sort out the details instead of trying to do it all in your head which is likely reeling from the chewing.

2. Categorize the talking points into the things you can fix, the things that you cannot fix and the things someone else can help you fix. This will help you to focus on the things you can change without the noise of the unfixable cluttering your mind. Put these on three different pieces of paper.

3. Take a deep breath and step away for a bit. As long as the pain is still fresh, you won’t be able to think very clearly and will likely make a few knee-jerk decisions ….. these will not serve you well.

4. After clearing your head, start formulating your get well plan. Plan out your actions taken from the meeting as well as what you can do to fix the things you could have prevented. This is your own personal lessons learned exercise.

5. Work with the person/people who can help you fix the things you cannot fix yourself. This may be a functional supervisor of a team member that missed key deliverables. This can also be your boss, or stakeholder … asking for help is not a further sign of failure.

6. Communication

7. Communication

8. Communication … keeping your stakeholders uo to date on progress,  risks, issues, and successes will only help to rebuild the trust that was damaged. Don’t wait for the status report, sometimes,  that is too late.

9. Throw away the items you wrote down that were completely out of your control or sphere of influence. You cannot do anything about them so stop looking at them.

10. Pick yourself up, dust yourself off and go fix it.

Every project manager will experience bad failures at some point in their career.  Sometimes it happens more than once. You are no different, but if you learn from the mistakes …. truly learn from them, then you can avoid making a habit of it.

Good luck, and power on!

What have you done to fix an imploding project?

2014 – Year in Review

As 2015 revs up, I can’t help but look back on the 2014 and think about all that happened, good, bad, and otherwise. There have been some successes, but mostly, I have had opportunities for . . . ahem . . . improvement. I got another year older, another pound heavier, and watched my kids get another year older too. I did accomplish many goals, however, and I am thankful for that, but I feel I might have been able to do more. Sure, I have five children and they take up a lot of time, but I’m not sure things were prioritized as they should have been.

As I look back, I am of the opinion that my resolve to #connect (see my post from January 1, 2014) may have fallen a bit shorter than I had hoped. Well, that’s okay, as I have more resolve left, and will overcome my own shortcomings.

Here are my yearly blog stats:

  • 8 blog posts
  • 630 views
  • 21 views on my highest day (all-time is 32)
  • 64 different countries (ok, that’s pretty cool to me)
  • Two sites (other than Twitter, and LinkedIn) referring (needs to be better)
  • 0 guest posts (ouch – need to fix this)

Not super stellar, but better than nothing, I guess. As for my personal goals, I did okay here too:

  • Finished reading the entire Bible
  • Renewed my PMP certification 5 months early

Sure, all of these need work. I am committed to working on them all and doing more in 2015. I know my beautiful and supporting wife will help me through it all.

Here are my goals for 2015:

  • Focus on the #OneWord resolution for 2015: #Prioritize
  • Read the Bible through again using the YouVersion app– this time in one year
    • If you don’t have the YouVersion app on your mobile device, it is available for free and is absolutely fantastic! (www.youversion.com or www.lifechurch.tv) If you do not know Jesus Christ, I’d love to connect with you to share the good news of what He has to offer.
  • 24 blog posts – that’s two a month
  • More than 1000 views for the year
  • More than 33 views for a single day
  • Readers from 65 different countries
  • Four site referrals (double 2014)
  • Be a guest blogger for at least one site

So, there it is, my personal goals for 2015. Feel free to hold me accountable and encourage me as I am sure that I’ll need both at some point. As a “hobby blogger” sometimes, things can get pushed aside accidentally.

If you have a topic you’d like to read an opinion about or to gain some additional perspective on, please let me know. I would love to write on things that matter to you most. I wish you a happy and prosperous new year!

Lessons Learned: Why You’d Better

Did you know that lessons learned during a project can be an enormously useful tool for your future projects? Well, I am here to tell you that they are, and here is an example. About a year ago, I was asked to work on a project where my team had to inventory IT equipment at a fairly large amount of sites. I had never done this type of project before but was more than willing to take it on. I had a single team member at the start and he seemed competent, confident, and ready to go.

We started out with a few test sites in which we were able to visit three sites in a single, albeit long, afternoon. My team member and I invited two other guys to accompany us to these sites just to make sure we knew what we were going to need to gather. Everyone understood that the product of this project was going to be an input to a much larger, more significant project a few months later. We were able to gather the data fairly quickly and even brainstormed a few ways to make the process faster, and of course, repeatable. We were good to go … so I thought.

$15,000 in travel and 700 hours of contract labor later, the end product was a spreadsheet containing approximately 1/3 of the data we were expecting. Oh, we also lost months of schedule. OUCH!

Now, we had a transition project starting that was the consumer of the data that the inventory project was to provide. So what went wrong?

1. I did not give the resource enough input to the schedule. I Googled the routes and gave them to him.
2. I did not allow time for any hiccups. I did not take into account the fact that using GPS coordinates does not translate into accurate directions.
3. I did not take into account communication with the sites prior to the visits which made for more than a few access and security incidents.

All of that is a massive recipe for failure, and fail, it did.

But after we looked at what all went wrong, we were able to make up that time during the next phase and not lose any ground. In fact, we finished early!

So, what did we do? We looked at all of the failures from the inventory phase and asked ourselves why they went wrong and how can we do it better. Some of the questions were tough as the answers pointed at the project manager on more than one occasion. As a result of these questions, and of the answers, I engaged the project team more as well as the sites. Everyone had a voice and everyone was on the same page.

Looking at the lessons you learned in previous projects allows you to use hindsight to fuel foresight? Don’t let previous failures be failures. Use those mishaps to your advantage. Turn those failures into success! Remember, fool me once, shame on you. Fool me twice, shame on me. Don’t repeat the failures of the past.

How do you use lessons learned? I’d love to hear your victory tales.