Nugget 11: Negotiating only works with the correct sort of deliverables, otherwise it can do more harm than good.

Explanation:

It is an automatic behaviour in a lot of managers to negotiate any quote or estimation of work, in a misplaced belief that all things can be dropped to their lowest ‘price’ and that this shows somehow that they are in ‘charge’. however as I have discovered in many a project, particularly those centred around internal systems and data with unknowns, that it is a misplaced economy, you may think that when you’ve negotiate a project down from 12 to 8 months you are getting the same product in a shorter period of time, but you are not, with a lot of such projects the quotations come from a technical source, which means that the quote is an honest belief in how long it will take to produce a quality product, knocking this down and making it faster doesn’t mean you get the same quality product, it means you actually get a rubbish product and long-term you have actually hurt the project far more than allowing a delivery in a reasonable time period, when you are dealing with both internal business and/or technical staff please be aware that the people might not be trying to make a profit out of you, they may just be trying to do a good job

Disclaimer: As always these posts are not aimed at anyone client or employer and are just my personal observations over a lifetime of dealing with both management and frontline associates.

Nugget 10: Just because in certain meetings everybody stops to listen to what you have to say because you’re the most senior person on the call, doesn’t mean what you have to say is actually useful, learn when to shut up!!

Explanation:

This is an easy trap to fall into and I have to say I still fall into it now, you are a manager of a team or simply the most senior person on the call, and whenever you say something, particularly when it’s third party vendors on the call, they will stop what they’re saying and pay attention to you and this attention is a drug!!, you see managers who do nothing but talk and talk, walking over other people’s conversations and ignoring the volume of the other experts on the call, just about everybody else on that call has a strong and valid opinion, they wouldn’t be on the call or rather they shouldn’t be on the call if that was not the case.

Yes, the most senior person on the call often has the responsibility of keeping the call moving and covering for blank spaces, as well as doing a summary and introductions, but try to not stifle other people, if you struggle on this, move to known call structures, such as round table where each person takes it in turns.

Disclaimer: As always these posts are not aimed at anyone client or employer and are just my personal observations over a lifetime of dealing with both management and frontline associates.

Nugget 9: Total time is not the same as work time.

Explanation:

it’s a well-known internet meme that managers will send an email in the middle of the night, then complain that their staff have not acted upon it by 7 a.m., That is time abuse on a basic scale. As a manager dealing with serious projects, you have to deal with this in a larger scale and ensure that you do not inflict it on your teams.

To explain this more, it’s best to realise that such time misuse can be compounded, it happens in multiple ways and in multiple situations, let’s look at some examples:

• You assume that everybody is going to work 12 or 14 or 16 hours a day to hit a deliverable.
• You assume weekends and holidays will be cancelled.
• You assume that the thing that you need doing is the most important thing ever, and even if that is true, you assume that nothing bad or unavoidable can happen to people.
• You assume that other work functions and other high priority items will not come up.
• You don’t realise that some items cannot be run in parallel or that some cannot be done at certain times of day and you might have to wait.

All of these add up and stack one on another and you end up thinking, “oh we’ve got a week to do that, that’s tons of hours, that’s 100 hours”, not realising that it really is only 37 that you can rely on, and even then you might be wrong,

Now I know this sounds like just ordinary project planning, but it tends to show up the worst during crisis situations, the worst time period I find is problems that need solving between 1 and 2 weeks, and as the time for delivery gets closer, you will find you become more unreasonable, you end up counting the actual hours left to the deliverable rather than counting the usable hours.

So to summarise, even if it’s a disaster, even if it’s a crisis, even if according to your senior client it is the most important thing in the world, the world will not stop, every hour is not available for you to use, plan accordingly, be honest with yourself and don’t ruin your teams life. 

Disclaimer: As always these posts are not aimed at anyone client or employer and are just my personal observations over a lifetime of dealing with both management and frontline associates.

Nugget 8:  If you are aiming for delivery then sometimes planning to take the blame is a valid project strategy.

Explanation:

OK this is another one where you will have to bare with me to the end. There are some organisations where fear of getting blamed for ANYTHING is overwhelming. This might be about only a single document or the ultimate delivery of the project, but whatever the level, a huge amount of effort will be put into avoiding actually getting something done, because only people who do things can do them wrong.

Such organisations might be Government departments where it is a job for life and the risk of loosing it might be too great, or merely one where things have stayed the same for a long time and any change is likely to be blamed for any bad thing that might happen, but nevertheless these places exist and as someone who is supposed to deliver change and improvement you have to combat it.

Working at multiple corporations and government departments I have found the easiest way of doing this is to take the blame yourself!!,  now you don’t have to do anything actually wrong to take the blame, you really just have to give the opportunity for somebody to blame you for something and then not defend yourself.

My personal favourite way of doing this is when there is a technical documentation delivery needed to get the project rolling, so you do it yourself for a first draught without the help of specialists within the business, this will most likely mean you will get things wrong.

That will give people the opportunity to go for you, the same people who are frozen into immobility will blast you, say everything is wrong and everything is your fault,  BUT it’s not actually a big deal because it’s a small thing at a beginning of the project, and now you have the project moving and you’ve got one more step closer to a deliverable, also these people feel empowered, they stand a better chance of running with the project and doing more, and all you had to do is have some thick skin and take some flak.

Now I know this sounds manipulative and cheap, and that’s because it is!!, but unlike so many other manipulative tactics, no one but you gets hurts and if you use it to get your project delivered successfully, then that is damage I think a grown manager can take.

Disclaimer: As always these posts are not aimed at anyone client or employer and are just my personal observations over a lifetime of dealing with both management and frontline associates.

Nugget 7: Agile is a useful methodology, don’t let it fall into the wrong hands.

Explanation:

The Agile project methodology is one of the best ways for actually getting things done, but like all solutions it is open to abuse, don’t let your managers and project managers twist it to be something it is not, or abuse it to make it fit with their own way of working.

Classic examples I have seen of abusing Agile are:

“Agile reporting”:  Which is just an excuse to get a daily status report while not actually delivering any help or assistance to your team.

“We work in an Agile Way”: Which is often a way of avoiding standards, structure or any kind of safety measures (or responsibilities).

You don’t have to follow Agile to the n-th degree, as that ruins the core principle and just replaces one form of paperwork with another, but try and stick to the basics.

Disclaimer: As always these posts are not aimed at anyone client or employer and are just my personal observations over a lifetime of dealing with both management and frontline associates.