Translating Analytics to Action: Right Metrics, Right Time

Translating Analytics to Action: Right Metrics, Right Time

Getting Thrown under the bus

In the course of human events as a project manager there will be a time.  Yes that dreaded time.   When regardless of what you do, you can NOT keep your project from going sideways.   And you might as well put "It's my fault" on your forehead.   Because you are going down.   Why is this?  Because it's always the PM's fault.   If the network has an issue, its the PM's fault.  If there is a bug in the code, it's the PM's fault.  If the project is over budget its the PM's fault.  If its over schedule, its the PM's fault.  If its under staffed, it's the PM's fault.  Lets face it.  Paint a target on your forehead because you my friend are going down.

How do you get around this?   You have to do your best to move past this point as quickly as possible.  Sometimes that remote install will require you to be on site.  If your code didn't go in correctly perhaps you need to be the one that helps out with testing.   Go the extra mile.   Push past the problem.   

Here are some tips

1. Keep in good relations with your boss.   Make him aware of your project status at all time.   Communicate with them on a personal level.
2. Keep your skills up to date - PM certification is key
3. Keep in good relations with your team.  Don't take anyone else down because of your misfortune.  
4. Sometime you need to fall on your sword.   If its your fault, its your fault.  
5. Stay up to date with job boards.  It does a lot of things for you.  What skills are people looking for?   What is the market doing right now?  Find out when you need to stay in your position and when you need to go because you might be in the market in the near future.
6. Over communicate after this happens.   For ex: We missed our deployment date but we are working on a solution and I will be back in contact as soon as I know the new dates.

Remember, IT groups are built on relationships.   Don't shoot the guy who could fix the problem for you.

7 Ways to Politely Shut Down a Conversation

7 Ways to Politely Shut Down a Conversation

Understand your business

Over the years, I have worked for many sectors of industry.   Distribution, Government, Consumer products, Insurance, Telecom and being a project manager at each business is extremely different in what the job entails.  The one common thread among all sectors is the expectation that you understand your business.   How do you understand your business?

First off, Ask questions.  It sounds simple but you will find yourself not knowing the questions to ask on Day 1, 2 or 90.  Your understanding of the business should grow and the types of questions should change.  Asking a question is not a sign of ignorance or skill level.

Second.    This is the hardest.  Listen.  You don't have to ask a question to get an education.  Sometimes you just need to listen to what the business is talking about or IT is talking about.   Eat lunch with different folks and listen to what they discuss.

Third.  Read what's available.   Sharepoint, project plans, who is the business representative.  Who are the architects?   What is the project cadence?  What's on an agenda?   What developement methodology is IT using?   Try to find the acronym chart.   Man does Telecom have a ton of acronyms.  I couldn't tell whether the acronym was network device or a business unit.   Read.

Attend as many meetings as possible to get acclimated.   Perhaps its an HR meeting where you learn company culture.  Perhaps another teams project meeting where you see their cadence.   Be present.  Meet people.  Let them know that you are there because you never know when your next project will be with one of your new best friends.

Changing priorities

Have you ever had one of those projects that was not at the highest priority for anyone except you?  What did you do about it?   Sometimes that takes some pressure.   Its called an escalation.  Its not to get someone into trouble.  Its to prioritize their work.  

So I would first off talk with your project team.  Ask them when they can complete the task.  If they cant complete the task within the needs of the project, then you will have to escalate to the manager.   If that method is not effective, I would have my manager/director escalate the issue.   So that is key point #1, Know your escalation chain.   Now that you have escalated, you will need to keep that escalation point aware of progress of their team.   Let them know if you are getting on track.   Key point #2, communication.   The escalation should not be the first communication that the escalation manager/director has received.  They should already be in the loop on Project communications.  They should have been notified by Key Point #3, The RISK Log update.   Once you identify a RISK to your project that should have been communicated out to the Project Sponsor and team.   One additional point, when you communicate out the RISK, that should not be the key that the rest of the team can stop working.  Sometimes your team is looking for a reason why they should stop working on your project.  Ensure that they know they still have deliverables and you are working to mitigate the risk.  If there are any change in timelines, communicate those out to the team.

Best of luck.

Joe

Stage Gates and waterfall

Once upon a time in a galaxy far far away, there was a development process called Waterfall.   In this development process, your project progressed in a step by step process.

1. Initiation - One pager
2. Planning - Scope Document
3. Requirements - Requirements Document
4. Design - Design Document
5. Test - Test cases and Test plan
6. Deployment

At every stage of your project was a stage gate where you would present your project in front of the PMO with leadership.   In this meeting you would walk your way through your project and at the end of your session, you would hopefully have a green light to move to the next phase of your project.   Most of the time, you would be required to have all of your sign offs from the previous phase before you moved on to your next phase.   Waterfall lent itself very well to this process in that it was a step driven development cycle.   The problem with this process was that you might not find out until Design that your project could only afford 5 of the 10 deliverables.   Also you might not find out until Design that you really needed to include additional scope that you didn't know about in the planning phase.  Easily corrected with a CR and additional funding but another problem nonetheless.   The other problem was getting people to sign off on a project that they really knew little about but they owned that sign off.  So I think that depending on your organization and how large it is, you might not really get the business involvement that you seek unless you are diligent about your communication.

Using MS Excel as your first Project plan.

You can use MS Excel to quickly timeline out your project without using MS Project.   Another PM shared how he projected out his project timeline and it has really helped me in the past to quickly put a timeline together.  The bonus it is quickly shared in email to your team as well.

Let me point out a couple of items here.   I manually put in the first two dates above.  Then I select those two cells and drag to the right to auto-populate the rest of the dates.   Then I insert my tasks.  Sometimes, I will create a line for each group.  So line one might be network, line 2 server team, line 3 security, etc.   To show what is done by each time.  More of a swim lane approach.   I find this extremely helpful in presenting to the kick off team.  Because this is really fluid and they can tell you  what might work and what might not work based on your projections. For example: there might be change freezes during a period that you didn't know about.  A task that you thought might take 2 weeks might take 3 weeks, etc.   Best of luck to you.