Blog

I recently met up with a former co-worker for happy hour. After getting caught up on the latest in our lives, she solicited my project management advice. She has been managing a high profile project where much of the project development is being outsourced.  Now, about 6 months into the project, which is scheduled to last a little over a year, she is definitely concerned.  The vendor responsible for multimedia development on her project is not meeting the service levels of the contract.

She went on to explain that in recent months, there have been integration issues across different contracted vendors. Because the integration issues were at the forefront, it didn’t seem odd that the multimedia deliverables were not being furnished at that time. Without an appropriate launch platform, this multimedia vendor’s product would not function. Early on, she reconciled any doubt: What is the point in asking this vendor for the products/deliverables when the functionality couldn’t be tested? Then, about a month and a half ago the integration issues subsided. When it was time to test the multimedia deliverables on the platform, a test file was provided from the multimedia vendor. While that served the purpose of testing, it also uncovered a hard reality – the parallel development that was supposed to have been taking place while the issues were being fixed was not, and her project was behind.

She and I employ similar philosophies when it comes to vendor relations: In order for your project to run smoothly, it’s important to maintain a good relationship with your vendors. So she did what I would have done – initiated discussion with the vendor, reviewed what was behind, and set milestones to get things back on track. Although things consistently ran behind schedule, she began to see some production. When the deliverables were reviewed however, they fell way short of the quality that was promised. The level of expertise and that she was outsourcing for was just not there. She approached that too with the vendor but to date, there has been little or no improvement.

After giving it some thought, examining the statement of work and determining just cause, she was now asking me: should she consider making a change?  Unfortunately, I explained, I don’t have an easy answer, but I did have some questions for her.

• Has this vendor assumed responsibility for the shortcomings? Most good vendors will be transparent about any issues that are occurring and what they are doing to remedy the issues, sometimes before you have to ask.  If yes, she wants to be certain that these are short-term and unlikely to occur again and there has been some sign of improvement.

• Are the quality issues cosmetic or functional? Although there shouldn’t be either, issues of the functional nature will likely prevent a release of the product. Cosmetic issues, while not optimal will likely not prevent the product release, unless the project success is contingent on appearance.

• Can the project withstand a change? There are surely cost and time implications if she were to bring another vendor on board. Those must be considered. Given what she told me about integration issues, ramp time may be significant.

I shared a story with her about a similar situation I was in where I decided to test the waters. I had gone the route of conversation after conversation and establishing milestone deadlines including withholding payment until deliverables were furnished. I decided to line up potential replacements and conduct some initial planning for a transition. Then I had yet another conversation with the current vendor on my project, this one a little stronger in nature. When I mentioned the potential for a change, he came at me with familiar promises of the past: we will improve, we will add more staff, we will iron out the kinks… I had heard it all before.  But to my surprise, literally overnight I began to see changes.  Secretly, I really didn’t want to make a change because of the effort involved, and turns out I didn’t have to. But if it were to have played out differently, I was prepared.

Summary

While, I did not have a solid answer for my former colleague, I let her know that in my experience, I have learned that that although switching vendors is not an easy task it is not an impossible task.  If you have just cause and have put forth a solid effort to work with your current vendor you have to explore alternatives.  With the appropriate planning and analysis, we as customers can certainly exit from an engagement with a vendor partner and begin with a new vendor with little or no impact.  As I check back in with her on her story, I will update you with her successes and challenges sharing her strategies, and or how she may have dealt with or will deal with making the transition.  Stay tuned…

by Lori

What if you found out part of the way through a technical implementation that the project funding was being cut by 15%?  Let’s say you’re 6 months into a year long project and you’re way past the planning phases…the heart of the work is being done on the end solution right now and you just got this bit of news dropped in your lap.  For an internal project it could be coming from your senior management or the internal business unit sponsoring the project and for an external project it would likely be coming from the customer project sponsor.

How do you handle this?  How do you react?  Short of throwing your hands up in the air and saying “I quit”, what do you do…where do you start?

This is a painful one to live through, indeed.  I’ve been subjected to sudden replacement (or loss with no replacement) of key personnel, changes in priorities of tasks by project sponsors based on business process requirements and of course the usual changes in requirements – sometimes very major – but I’ve not run into a decent size budget cut scenario, like this…though I find it intriguing to consider.  As you read through my thoughts on this, think about your own experiences…how did you handle something like this or – if you’ve never experienced it – how do you think you’d react and what actions might you take?

Here are my thoughts:

First order of business – assess the current project budget

Are there places where the budget may have been inflated?  Can a few tasks be removed from what’s left of the project to help make up that 15%?  Can a key deliverable be removed?  Can a report be eliminated now and implemented after deployment if it is truly deemed necessary later on?  Scour the requirements and look for things that aren’t absolutely necessary that can possibly be removed to save portions of that 15%.  Don’t try to go for all of it here…service may suffer.

Next, assess the current project team

Are you keeping resources on the project that may not be needed?  Resources tend to charge to the project even if they aren’t doing much – most organizations want to see as close to 100% utilization as possible and if a resource has a project on their plate, they are likely to charge at least some time to it each week.  Go lean – manage the budget with an iron fist and see to it that no time is charged to the project that isn’t absolutely necessary.

Look at any vendors being used on the project for opportunities to cut costs

If you’re using any 3rd party vendors on the project, can you negotiate some better rates on their services or go with a different vendor at this late stage in order to save some meaningful amount toward that 15%?  Of course, it’s critical that you don’t do something drastic that could cause some failure point on the project so that’s a key decision point for the project manager.  But often times you’ll find that vendors would rather cut a price than be completely cut out of the picture as a service provider.  Negotiate…it’s definitely worth a try.

Consider changes to deployment related activities

Are there things – tasks, activities, deliverables – that you’ve priced into the engagement near deployment or after deployment that can be eliminated?  It’s not wise, but you can cut the lessons learned session from the project.  Circle back for free with a one on one phone call with sponsor on a lessons learned quick call…it’s still better than nothing.  Or possibly some documentation deliverables could be eliminated (not wise, but maybe a drastic necessary move) or given away for free.

Summary

The key concept may end up being this: if the cut is coming from the customer and they are a valued customer, you may need to just eat that 15% and do that dollar amount of work for free.  Is retaining this customer’s business or getting a good referral from them of utmost importance?  If the answer is a definite ‘yes’, then you may have no other choice.   If the project is internal and the order of funding reduction is coming from your senior management, then it may be a concerning revelation about your company’s financial situation.  You still can’t do anything about it but decrease services on the project – cutting staff just means someone else has to work harder and that effort will still hit the bottom line of the project…so no real help there.  It’s not likely you’ll find one thing to cut to save the 15%.  It will probably need to be minor reductions in a number of different areas on the project.

by Lori

We are finally at the last installment of the five part series on delivering a quality solution to your project customer.  So far we’ve covered:

• Kicking off the project right

• Planning and forecasting the effort well

• Managing the schedule

• Planning and preparing for testing

In this final installment we’ll cover a concept that, unfortunately, is often overlooked on IT projects…or any projects…believe it or not.  It’s the concept of documenting the end solution for the project customer.

I realize there are times when end user documentation and very detailed documentation on a configured end solution for the project client is required and is a significant deliverable at or near the end of the project…right around deployment time.  And often that has formal review and acceptance tasks wrapped around it.  But that’s not necessarily the norm – it’s more of the exception.  At least that has been the case on most of the projects I’ve managed and that my colleagues have reported to me – unless they were large government contracts and then those types of deliverables are usually fairly mandatory and well compensated.

I feel strongly that end user documentation should be something you deliver with every project.  It can be a “how-to” user guide, possibly even written at a high-level.  It can be very detailed documentation on the end solution identifying how the product or solution was built or configured thus providing detailed information to the customer’s support organization as support for the solution shifts from the delivery team to the customer’s own organization or the support staff at the delivery organization…depending on what was agreed to during sales and/or kickoff of the project.

Failure to document

I worked for one organization for two years as a senior project manager that had their own proprietary software.  My projects were always focused on taking that software and configuring it to work for the customer in their environment and with their business processes so it was meaningful and useful for their end users.  I liked to tell people that it was a great product right out of the box, but it didn’t work for anyone until you configured it for their business.  But delivering end user documentation detailing what my team did to modify the product for the user was not something that was documented well and not a deliverable that was handed over to the project customer.  In fact, in two years of leading these projects that usually lasted for months, only one customer ever asked about getting documentation for the configured end solution.  It was never something that was priced into the engagement by sales and it was never a deliverable that was built into the project schedule.  I’d like to think that our end users would have been even more satisfied customers had they been given such a deliverable.

Summary

The bottom line is this – as we build a solution or run a project for a project customer or consulting client or whatever, we should be working with that end documentation deliverable in mind.  It SHOULD be something we price into the project (and the level of detail – which would dictate the price of the deliverable – should be jointly agreed upon with the customer).  Build it into the schedule, work each of your projects like it’s an expectation at deployment time.  If you already do this or your organization knows it’s important, I commend you.  If not, then it’s something that should be seriously considered as you examine your project management life cycle and methodology next time around.

by Brad

We are now at Part 4 of the five part series on steps we can take to deliver a higher quality end solution to our project client.  In this installment, I want to consider a way we can help our project and our customer, but not do the work for them, of course.  What I’m talking about is preparation for customer acceptance testing – generally referred to as user acceptance testing or UAT.

The act of testing a solution – especially a technical solution that we are planning to rollout to a client that will be used to hopefully very positively and significantly impact their business going forward – is no small undertaking.  Of course the delivery team is responsible for performing their own testing of the solution prior to acceptance testing by the customer.  But the most critical testing that is performed happens when the customer puts the end solution through its paces with the keen insight into how it needs to work in their environment, under their business policies, practices, and processes and with their end users and potentially their own customers.

Again, we can’t do UAT for our project clients, but what can we do to ensure the solution is well tested and ready for signoff and then deployment following UAT?  In my opinion, and from my experiences, we can do these three things…

Plan well for testing

First, we can plan well for the actually timeframe and effort of user acceptance testing.  By this I mean we need to make sure we have the proper amount of time built into our project schedule to ensure the solution is ready for UAT, the environment is ready for the customer to test it, the customer – and our delivery team – have enough time to prepare materials for UAT, there is enough time allowed to thoroughly test the solution, and proper time is allowed for reviewing and signing off on the user acceptance testing results.

Educate the client

Next, we can educate the project customer.  Unfortunately, most customers are lacking in test preparation skills as well as having the right personnel and enough personnel available to thoroughly perform UAT as it should be performed.  We are the experienced resources on the project.  We may not know the most about how the customer’s business works – though as the project is getting underway we are likely fairly well versed in the business processes at that point – but we are the experts on the solution, how it will be developed, and how to thoroughly test a solution to ensure that it is ready for deployment.  We can educate them in the process and explain what has to happen and when it has to happen in order to meet the deadlines set in the project schedule.  We can provide them with our own examples of good test cases and meaningful test scenarios for performing the UAT and running the solution through its paces.  We can’t do the testing for them and we should never actually write their test cases for them – that would be a conflict of interest – but we can certainly show them examples of what they should be developing for UAT.  And most of all we can help the customer understand what personnel, equipment, and support they will need in order to perform a meaningful user acceptance testing.

Walk them through it

Finally, we can hold their hand through the actual process of user acceptance testing.  We can be there to support them throughout the process, perform quick fixes when issues arise or if any part of the solution fails a test, and we can help them with any technical issues along the way.  It’s also in our best interest to make sure that UAT goes smoothly and happens in the required timeframe, so this step is definitely a win-win for both sides.

Summary

Performance of a thorough and meaningful test by the customer of the final project solution is critical for every project.  Anything we can do to help ensure that UAT is performed well and that signoff is achieved on the solution will help all stakeholders on the path to deployment.  And a good UAT will help ensure a quality solution is delivered to the customer.  That’s our goal and it should be the goal for us on every project.

by Brad

Change is upon us. Come July 2013, PMI will be adding a new section to the PMP called Stakeholder Management. As you may already be aware, in the current edition of PMBOK, this information is primarily covered in the Communications section. So why the change? There seems to be a general consensus that this is one area for which Project Managers seem to struggle. I remember when I was going through Boot Camp in preparation for my PMP, the instructor ingrained in our brains: “Remember… everyone is a stakeholder…”. That information served me well when I took the exam, as did the information in the PMBOK, but frankly I have a different take on why this continues to be an area of opportunity. You can’t manage stakeholders like you manage tasks or projects.

I remember a former colleague of mine who consistently complained about her stakeholders. “I don’t know why he’s calling me and asking those questions, I listed that on the status report last week…” or “I sent him the deliverable to review and sign off on three days ago and he still hasn’t responded…”.  Those were good, but the one that really got me is when I asked her to explain what happened when she was at the end of one of her projects and facing a significant amount of re-work. Her answer: “I did a stakeholder analysis and it revealed that she wasn’t as influential as some of the others so when she didn’t respond to my request for a signoff, I deleted her off the email’s…” .  Really?

Stakeholders aren’t always consumers of the end product, but still should be regarded as our customers. We are there to serve them.  If you are a waitress and you bring food to a table and the customer doesn’t eat it, are you just going to ignore that customer until they do what you want them to do – eat the food? I certainly hope not. My hopes are that you will continue to check on them, ask them if it is hot enough, ask them if they need something else, and perhaps refill their drink.

As Project Managers, we may do our due diligence by determining a stakeholder level of influence, put them on our weekly status distribution, or check them off on our list of attendees when they attend our project meetings but if we fail to connect with them on some sort of level, we may see another section called Stakeholder 911 being added to the PMBOK.  I still have some challenges in my attempts to engage my stakeholders, yet I have found some ways to consistently improve the overall experience.  By employing these strategies, I have noticed that I have less and less project issues resulting from stakeholder concerns.  I call these strategies the 4 R’s to creating a Stakeholder connection:

• Rapport – sure it may be more efficient (c’mon I know how us project managers think) to put together a group call for introductions,  getting it all over at once, but that way you are missing out on an opportunity to establish a rapport.

• Results- If it is not immediately apparent, during your conversation with the stakeholder, ask some questions about their business challenges and results for which you may relate back to the project outcome. Make it clear how project efforts are going to help them overcome challenges or fulfill a business need.

• Relax – I know it is really important for you to show them how awesome you are at crunching numbers or assembling meeting minutes, but start out your emails or calls by telling a short funny story or end by saying have a nice weekend.  Don’t digress to the point you are wasting their time, just set the tone for a more relaxed interaction.

• Reward – A simple thank you goes a long way. If you can find a way to express your gratitude for their help- that also can also make a difference- maybe it is meeting at the coffee shop and you buy, or your bringing in lunch for a meeting.  By no means am I advocating bribery, but by these types of gestures you are showing an appreciation for their time and also showing a human side not always apparent when we drive the agendas of our weekly status meetings.

Summary

While the change in the PMBOK is a welcome acknowledgement of how important stakeholders are to a project, let’s not forget the importance of balance.  Employing process- based strategies will serve us all well by ensuring we remember who we are accountable to and how they can influence the project outcome. Balancing these strategies with creating a connection can not only improve your chance of project success but also carry over into other projects, and maybe even improve how you are viewed in the organization.

by Lori

In the first two parts of this five-part series on delivering a quality project solution, we covered:

• Kick it off right

• Plan it well

In this Part 3, we’ll discuss the idea of effectively managing the project schedule in order to maintain an organized project and to better your chances of providing an on time quality solution to your project customer.

Importance of the schedule

Why is the project schedule so important and why do we have so many tools available to help us manage the project tasks, resources and timeline?  The answer is probably obvious…without a project schedule every project manager would just be ‘winging’ it.  You could use a checklist to check off tasks as they are completed, but that doesn’t help you manage progress on tasks and to report on what’s past due and what lies ahead.  Those are critical when you’re trying to keep a large project on time and a customer happy in the process.

The project schedule starts as a draft from the beginning of the project and remains a work in progress throughout the engagement.  It is the single most important tool the project manager will ever use to manage the project.  And for me, it – along with the latest project status report – is the driver for my weekly status calls and meetings with the project team and the project customer.  The project schedule should show you a snapshot at any given time of what state the project is in:  what tasks are on time, what tasks have completed, what tasks are coming up, and what tasks are overdue…at a minimum.  And, ideally, your chosen project management software tool will show you these critical areas using filtered reports or dashboards.

The  best way to effectively manage the schedule – and, ultimately, the overall project – is to keep the project schedule up-to-date on at least a weekly basis.  Unchecked project schedules can quickly get out of hand.  And just like it’s easier to fix a project budget that is 10% off than one that is 50% off, the same goes for the project schedule.  The efficient project manager who is revising the project schedule every week with new tasks assignments and task progress updates will likely not get so far behind on the project timeline that they can’t take corrective action to get back on track.

Getting updates from the team

Revising the project schedule needs to be a collaborative effort – otherwise the project manager is just ‘guessing’ at project tasks updates.  I make it a habit to conduct internal weekly project status meetings with my team to get their input to the project schedule updates and project status updates.  That way, I’m revising the project schedule with the most current information prior to the regularly weekly formal status call or meeting with the project customer.  And we’re all on the same page going in so we can have a very productive and proactive discussion with the project customer concerning the status of project tasks and issues each week.  Productive weekly status calls serve to keep customer confidence high that the delivery team and project manager really are in control of the project and that a quality solution is likely to be delivered.

Summary

Unfortunately, there is no amount of project schedule oversight and input that the project manager and team can put into it that will guarantee a quality solution and an on time delivery.   But if you treat the project schedule like the important tool that it is – basically the overall driver and really the ‘bible’ of the project – then you know you’re focusing on the right area of oversight.  The project schedule is the list of every detailed task that needs to be performed on the project to accomplish and deliver each deliverable, meet each project milestone, get through testing, and make it down the homestretch to a quality end solution.  Give it the proper attention and oversight that it needs and you’re more likely to meet the end goal of providing a satisfied customer with a final quality solution that their end users can productively use going forward.

by Brad

Kevin’s manager has just broken the news to him: business is down and the company has just let go of a quarter of its workforce including some of the Project Managers, 2 from Kevin’s team. Kevin feels flattered that they decided to keep him. They recognize that he really deserves to be there, perhaps an acknowledgement of his consistent deliveries on time and under budget.  Kevin is a caring guy, so his subdued reaction to the news appropriate. As a courtesy, Kevin goes out on a limb and offers to pitch in to ensure the workload is addressed. He feels it is something he is “supposed to” say and besides, no one ever really takes people up on these things. That is until now. Kevin quickly learns of his fate. In addition to being one of lucky ones to remain on staff, Kevin is now responsible for Bob’s projects.

Bob. Heck of a guy. Ran the office March Madness brackets every year, always good for a joke or 10, and organized the company softball league. With all the charity, folks wondered how he got anything done.  As Kevin peels back the layers, he quickly learns that Bob didn’t get much done at all.

Sound familiar? There is a really good chance that you have experienced the same thing as Kevin – what I call the “great” inheritance. Whether someone goes on leave, vacation, leaves to pursue other opportunities, or in Bob’s case is laid off, someone like Kevin is left behind to pick up the projects (or pieces).  It isn’t always bad. While a project may not meet to your exact specifications, it still can be left in decent or good condition.  But what about those that aren’t? How exactly does one take a sideways project, turn it around, and make it their own?

I’ve personally been there. In situations as described above and even once I was required to take over a project alongside the very person that ran it off the track. These are trying situations, to say the least. I have included some of my key Do’s and Don’ts to making the most of the “great” inheritance:

• Do – Survey the damage – Review documentation if available, talk to the team, and most importantly, the project sponsor to get their perspectives. Once you have done this, commit to moving forward.
• Don’t – Fix what isn’t broke – While these sorts of projects have failed in some way shape or form, there are likely salvageable components. Although not perfect, some things when left as is will not compromise the end result. You will know what these are when you survey the damage.
• Do – Take time to personalize – There is nothing worse trying to fit a square peg into a round hole. Although you don’t want to re-do everything, you may have proven systems that work for you. Where you can, implement your systems and processes that you know work and are essential to project success. Be sure to communicate any changes to the team.
• Don’t- Come with a chip – Just as Kevin felt flattered that he “survived” the reduction in force, it is easy to get caught up in a savior’s mentality- “they picked me to come to the rescue because they know I am good…” While this may be true is the worst trap you can fall into.  Loose the chip, and always avoid the blame game.
• Do – Create a POA- Or plan of attack. When you re-engage in the “battle”, you need as many on your side as possible. Make sure you have the right people (sponsor, stakeholders, SME’s) on your side. You can win them over by being a good listener and taking action.

Whether good or bad, it’s never easy picking up someone else’s project. Once you know how and why the project went astray, you can use it to formulate your go forward plan. While cockiness is not likely to get you far, find solace and confidence in your own proven project processes without sweeping reform which is likely to further delay an already troubled project. How you pick up the engagement and forge on says a lot about you and will likely define your success with the team and project.

by Lori

In Part 1 of this five part series on delivering a quality solution to the project customer, I discussed the process of kicking the project off well in order to properly set expectations for the rest of the project engagement.  In this Part 2, I’d like to discuss some of the planning, forecasting and oversight that is critical for the project manager and his team to perform.  Not just the initial planning documents – that’s another step in this process.  Rather it’s the concept of the proper resource, budget and schedule oversight that is necessary for seeing a project through to a successful end solution delivery.

Planning the effort

There’s much work that has to go into planning the work on the project.  It started before kickoff – as discussed in the first article of this series – but it continues throughout the project…it never ends.  Resource planning, budget forecasting and reforecasting, finalizing the initial project schedule and then tweaking it likely every week for a weekly status review with the team and customer – it goes on and on.

Resource planning. Let’s start with resource planning.  Most of the organizations I’ve worked in or with don’t assign everyone to the project at kickoff.  And that’s usually a good thing because they would be hitting the precious project budget with at least some sort of costs possibly long before they are needed for any effort on the project.  It’s up to the project manager to plan when resources need to be onboarded to the project for maximum usage and efficiency and to present that plan to the resource gatekeeper in the organization.  Likely they’re looking for a skill set, not a specific resource name, from the PM and then you’ll get who you get – at least that’s how it’s worked in all of the matrix organizations I’ve been involved with.  So it’s critical for the PM to know what skills they need and when…and then likely fight for the individual who best meets that skill set.  It’s all about getting the right resources who can deliver successfully and make you look good.  I know that sounds weird, but at the end of the day you are judged by the success of the project – so if you look good so does the project.

Budget forecasting and analysis. Start with the budget that was given to you – you really don’t have a choice because that’s the price for the effort whether you agree with it or not.  If you can’t make it work, then you need to raise a flag early.  If it’s because requirements were different than what was originally perceived, then change orders may be needed to set the budget right.

Once the project is underway, it’s critical that the project manager is continually revising the budget with actuals and reforecasting it.  Staying current on the budget every week can mean the difference between a fixable 5% budget overrun and an out of control irreparable 50% budget deficit.

Project schedule oversight. Baseline the project…no doubt about it.  But it’s a reality that you’ll be revising that project schedule every week.  It should be the key weekly project status meeting driver – along with a formal status report – for discussions with the team and customer.  On a weekly basis all task status’ need to be revised and I highly recommend setting up filter reports – if your PM software of choice allows it – that will show you what tasks are in progress, what tasks start next week, and what tasks are past due for completion.  Having these available for each meeting can keep small issues from becoming showstoppers on the project.

Summary

We all want to jump into new assignments and start working.  Showing progress to our customers and our management is ingrained in us…too much planning can make us look unproductive, I realize.  But it’s imperative to have the budget forecast, the resource plan, and the project schedule in their best possible state of completeness and detail going into the project because they will be items that we must access, review, and usually update on a weekly basis in order to maintain our overall project health by keeping the project on time and on budget.

by Brad

There’s project management performed by shooting from the hip and then there’s project management performed by going meticulously through a series of processes and procedures planning everything to a tee and following PMI policies like a bible.  The latter may be for you and it may be necessary for a program like NASA, but I think on many projects we all fall somewhere in between.  I’m of the opinion that the ‘shooting from the hip’ method is a really bad idea unless you’re managing a $2,000 project lasting a week or two.

What I’d like to discuss in this five part series is not how to do everything by the book, but rather touch on five key areas that are often weaknesses for project managers – areas where we often hit bumps or don’t get it right every time.  I’m not saying this series will guarantee you’ll get it right, but I wanted to share my thoughts on these areas and discuss how I usually handle them and increase the quality on my projects more often than not.

In Part 1, we’ll look at the things we can do to kick the project off and start it down the right path from the beginning.

Kicking the project off

How many times have you been handed a project and given a few details and told ‘go!’?  If you’re like me, far too many, I’m guessing.  Wouldn’t it be nice if PM could be part of the engagement process?  Part of that ‘close the deal’ situation with the project customer where the price is estimated, the draft schedule is conceived, and milestones and deliverables are planned.  This is where many key high-level requirements are discussed…then, unfortunately we leave it to an account manager to pass along to us non-technically their technical account of what was discussed.

Welcome to the real world…  Given that the PM often doesn’t have that initial access to the customer when they are still a ‘potential’ client, here’s the process I try to follow for getting from knowledge transfer to kickoff…

Meet with the deal closer.

Assuming receiving the news that you’ve been assigned this new project is your first heads-up, then your immediate tasks are to familiarize yourself as much as you can with the customer, the requirements, the budget, the deliverables…everything…before you ever talk to the actual customer.  So that means you go to the account manager or whoever it was in your organization that closed the deal on the project.  They have whatever was used to put together a price, a rough schedule and likely a statement of work (SOW).  Those – along with whatever ‘notes’ they have like a report mockup, etc. – are your starting points for putting the planning phases of the project in motion…starting with a formal kickoff.

Introduce yourself to the customer.

Depending on the timeframe of the engagement and the urgency to get started, this step in the kickoff prep process can happen before or after you re-work the draft project schedule – my preference is to do it prior to touching the schedule as information you gain from this introduction may help you put a better initial schedule together for the engagement.

Contact the project sponsor, introduce yourself…perhaps even offer a resume noting your relevant experience if the project is a very high dollar, long-term project.  You want the comfort level of the customer to be high as the project starts – it’s hard to raise it later as the project undoubtedly encounters issues that just happen on any given project.  Give the customer an idea of how the process will go – let them know you’re putting together a presentation and materials for a formal project kickoff session and get that session scheduled so key stakeholders can put it on their calendar.  Try to get the sponsor to limit participation on their side to only necessary attendees…some customers want to bring everyone to the table and it can definitely limit productive discussions.

Fix or create the project schedule.

Likely, part of that deal closing involved a draft project schedule that – at least on some level – showed the customer that your organization could, indeed, deliver on this project and showed an understanding of the deliverables involved.  Take that draft project schedule and make it your own.  Insert the key PM check points, review points, signoffs, and meetings that you know better than anyone else need to happen to keep the project running smoothly and to properly deliver the solution.

Put together the presentation.

I usually put together a deck of PowerPoint slides for formal kickoff sessions.  It’s up to you how you want to do it and the size of the project may dictate how ‘formal’ the kickoff session actual is.  The key is to go through the SOW and any assumptions and make sure expectations are properly set.  So plan accordingly.  It’s a good idea to use this presentation to map out how you plan to manage the project including methodology, meetings, communication, deliverables, and definitely change orders.

Conduct the kickoff.

Finally, conduct the formal kickoff session.  This is where key expectations are set, questions are asked and answered or action items are taken down and followed up on the next week.  Take good notes and send out those detailed notes to the project sponsor to ensure that everyone moves forward into the next phase of the project on the same page.

Summary

In an ideal world the PM would be part of the engagement process from the outset and by the time he was preparing for an actual kickoff session, that PM-project sponsor relationship would be solid and you’d be completing each other’s sentences.  Some organizations have both the vision and the luxury of enough resources to make that happen, most do not.  But that doesn’t mean we can’t plan and prepare appropriately for a formal project kickoff.  It can turn out to be the most critical meeting of the project because if you don’t get it right, you may find yourself playing expensive catch up for then next few months on the engagement.

by Brad

It’s the end of day Thursday. This week you have overcome some brutal meetings with the client, survived multiple resource related issues, and endured your computer crashing and subsequent IT restoration. But hey no sweat, by comparison this was a good week… and well, tomorrow is … uuugh, tomorrow is…<sigh>…unfortunately Friday.

Most people celebrate Fridays. PM’s hate them. While their project resources bounce into the office in casual wear and head out to their extended lunch, you may walk by a PM’s cubicle, see the chains secured to the desk, and hear nothing but grumbling.  You see, for most PM’s, on Fridays status reports are due.  While PM’s expect their resources to be proactive about their own deliverables, they have waited until Friday, the day its due, to start their own. But who can blame them? Barring any unforeseen emergencies, days of the week are filled with meetings, conference calls, and at least a hundred emails a day most of which are marked for urgent review.  And, you know what they did on Wednesday? They explained the status report from the previous week to their manager. You know the one where almost every deliverable on the status was marked for immediate escalation? Given that the status from LAST week was discussed on Wednesday of THIS week –they have since implemented work arounds, fought the good fight, and moved on. Everything they spent hours documenting is now in the rear view mirror, obsolete. There is an entirely new set of issues from THIS week that they will already have fixed by the time their managers ask about NEXT week’s report.  And so, as it always goes on Friday, the fire drill begins. Collectinginformation from multiple sources, getting progress on deliverables from each team member via calls and emails (except they are all out to lunch), then consolidating it all for each one of the projects for which the PM is responsible.

I firmly believe that one of the single most important qualities of a good project manager is superior communication skills. Therefore, at one point, I too thought this status report exercise was a necessary evil, it folds up underneath the superior communication quality, and that there wasn’t anything I could do about it.  But then I got to thinking, and upon further review, I had a revelation. Equally as important as our communication skills, are our abilities as PM’s to problem solve. I finally arrived at the conclusion: I need to approach this differently; dare to dream, take back my Friday’s.

At one point, I too was (very) irritated by the amount of time that goes into the task of status reports. For a very long time, I typed data into a document for status reports, shifting to a spread sheet application to track issues and risks, then onto a completely separate application to update a project plan, and yet another tool to communicate with my project resources.  When I really got to thinking about it, this went way beyond just irritation with just status reports.  I thought about how my small issue of a status report was really a broader issue about efficiency.  Between the time it takes to hunt down team members for progress reports, bounce back and forth between applications, and explain to my manager information that is no longer relevant…how much is this costing my organization and what am I willing to do about it? I did some research and developed a new approach to putting status reports. It combined technology and some new practices. Next, I formed a coalition with my peers. I began the crusade with words like: “Imagine a world where you could take a lunch on Fridays…”  Together we worked on the solution until we came up with something that works and that everyone could get on board with.  I won’t go into the details on the exact solution, but I will say, I like Fridays again.

Have you heard the saying: “It is not about the message, it is about the delivery”?  No matter how often you shoot your manager a stink eye as you discuss how you have fixed all the issues you are now explaining yet again, or how often your co-worker hears you grumbling at your desk on Fridays, no one is going care about it unless you show how you can fix it. If I could only have the time back that I spent being miserable on status Friday’s, or all the time I have spent complaining to my peers about other inefficient processes. That takes way longer than it took to find a solution.

I recently wrote about demonstrating the value of our projects by documenting their return on investment (ROI).  I think it is just as important that we focus in on ways that we personally can add value. Ways that we can turn what feels like resignation into opportunity. For me it was figuring out a better way to communicate status.  For you it may be something different.

Status reports… can we do anything about them?… You bet we can.

by Lori

Nobody is perfect…no matter how highly we regard ourselves and our skills.  And as project managers, most of us are learning along the way – I know I am and I’m 20 years into this profession.  One thing I have learned is this…there are a few key things we must make sure that we – as project leaders – avoid repeating on our projects time and time again as they only lead to difficulty, confusion, customer frustration, and sometimes project meltdown.  The list can be longer – much longer – but I’ve narrowed it down to these four key items:

Assume the project budget is meant as a guideline

The project manager is handed the project with a price tag on the project.  Period.  There is always a price tag.  Whether it’s an internal estimate or price on an internal project, or it’s a price quoted to your project customer.  Yes, that may be the only price your customer – internal or external – is going to see and pay.  Or they may be getting billed for the ‘real price’ – the actual cost of the work you and your team is doing.  Either way, the budget is yours to manage…even if you were never really given it to manage.  If you weren’t given the budget to manage, then seek it out and manage it.  Because at the end of the day, you’ll be expected to answer to it – either by your senior management if you’re leading a ‘fixed price’ engagement or by your customer if they are getting billed the real cost of the project work you’re doing.  If it’s higher than was originally quoted or planned, you’ll be answering to it – so know it and manage to it.

Overlook small scope changes as small

No scope changes are too small to just let pass through.  You can keep some in your hip pocket as negotiating points on larger project issues, but you and your team must always be aware of the scope of the requirements and alert each other and the customer of work that is being done or requested that falls outside of that scope.  It isn’t always easy to do or to recognize, that’s why it requires managing.  By overlooking several ‘changes’ to the project scope, you can easily find yourself falling outside of the project budget and you may not know why and you’ll have no documentation or additional customer revenue from the changes to save yourself when you have to answer to the budget overrun at deployment time.

Treat risk management as an optional item

Risk is risk.  It’s called that for a reason – and on most projects at least some of that risk you identify at the beginning of the project becomes a reality.  Conduct risk planning and identification sessions up front on the project and ready yourself and your team to react to that risk.  You won’t catch everything, but you may end up saving a project you would have otherwise lost had it not been for some proactive risk planning on the project.

Assume the project customer knows what they need

The customer almost always comes into an engagement with their own ideas of how to solve their problem.  And our mistake as a project team can be two fold in those cases…first we believe that the customer knows what their real problem is and, second, we believe that they know how to solve it.  If we’re busy and take them at their word, we are the ones who will get blamed for the project failure later on when we implement the wrong technology or a solution that doesn’t meet their needs.  Take what the customer comes to you with and set it on a shelf, then do your own discovery work.  Go to the end users and subject matter experts (SMEs) in the customer organization.  Don’t assume the sponsor has gathered all of the necessary info or even asked the right people the right questions.

Summary

What we fail to correct or observe are the very mistakes that we are destined to repeat time and time again.  ‘Too busy’ is never a good excuse, because expensive re-work later in a project will kill the budget and the project manager and team are the ones who will be on the hook.  Do it right from the beginning.

by Brad