Talk

Advanced search

advice for recent SAHM about planning (?) jargon?

(17 Posts)
Dateloaf Thu 13-Aug-15 07:50:17

I have just started a new job in a company after a few years of SAHM and am freaking out. The professional jargon all of my new colleagues use is new to me. it feels like a (planning?) technique but I'm too embarrassed to ask colleagues as I'm worried they'll find me unprofessional. It's a very male environment with few other working mothers.
It's all 'workstreams', 'deliverables', 'dependencies', 'risks and issues' everything is 'logged' according to a traffic light system and your 'outputs' are measured.
Where can I read up on this system, and is there a qualification which I could work towards?
We literally don't speak the same language at work and I'm finding it very stressful. I also feel at sea because I am employed as a specialist on an area of work the company wants to get into. Problem is that my work is not always predictable to the timescales they want to be dictating/mapping out in advance and holding me to.
They are putting firm delivery dates against 'deliverables' I don't think I can guarantee to deliver by a set date. (E.g. a typical task might be 'develop relationship with external stakeholder and influence them to form and implement a favourable policy to my company by X date'. Then if they don't do it by that time I will be held to account).
I am worried about my performance being measured solely on 'results' I am not in control of, rather than 'effort' which clearly I am in control of. eg 'delivering' decisions from complex external organisations which I can obviously seek to influence but can not ultimately dictate.
I don't have the technical language to explain to my colleagues why this planning/performance management system is problematic because it does not seem to account for uncertainty about if or when the end of the task is achievable by. how do I get them to accept that the end result of the task is not always something I can produce myself and the desired result is up to a third party to provide- and the third party might not agree with our approach?
Clearly all this logging is about eliminating any delay to their plans/the companies' needs so I am starting to feel I will be soon inevitably 'failing to deliver.'
I am really hoping a kind person on here can tell me if there is specific terminology for situations like this so I can try to talk it through with them again. My attempts to do so in non technical language seem to be not cutting any ice so far.
I have no peers or seniors who are from same subject area or with this same type of role to ask about this. Thanks very much for reading if you have got this far! grin

HeadDreamer Thu 13-Aug-15 07:59:08

I don't know what area you work in. And I'm not sure what you mean by technical language either.

But uncertainties you mentioned are risks. You raise it at meetings. Do you have any plans to mitigate such risks as you see it? Do they agree with your assessment? It is about communication within the team.

FusionChefGeoff Thu 13-Aug-15 08:28:05

I don't recognise the specific terms but can definitely sympathise that companies (even groups or departments within companies) create their own language, buzzwords and jargon. For tribal identity, creating extra 'perceived worth' to mKe them look more knowledgeable..., etc etc.

Basically, it's much more about them creating this 'identity' using language than a reflection on you so don't be nervous.

Don't be embarrassed if there is a specific term that you really don't have a clue on - it's much more important to get clarification to make sure you are doing what you need to do. Try out some different phrases - "I've not heard that used in relation to x before - is it the same as....." Or "I've used "widget" before to define x, y and a. Would you say that "dewberry" is the same?" Or identify a friendly ally and make a joke about needing a translator in some of the meetings and see if you can whizz through a few quick definitions in one go.

Regards to your individual targets, all targets should really be SMART - Specific, Measurable, Attainable, Realistic and with a Timescale. Have a read up on it for some examples if you've not come across this before. Sounds to me like they might be missing on the "A".

If you feel that your deliverable is out of your direct control, could you offer another level which breaks that target down into things that you CAN do. So in your example could be "meet with x 3 times over next quarter" "present paper to x outlining our position" "get introduction to 2 new contacts in x organisation"

You have then done everything in your power to influence them but ultimately, acknowledge that you can't control their decision.

FusionChefGeoff Thu 13-Aug-15 08:32:16

Just re-read your OP and although I said make a joke about needing a translator, it might not be a bad idea to actually look the words up in a dictionary / thesaurus and try to align the possible definitions to the context to try to come up with a 'plain English' version of the system which you could offer to someone else for them to check / confirm.

FusionChefGeoff Thu 13-Aug-15 08:33:16

It does sound very project management based so maybe from the PRINCE qualification?

Dateloaf Thu 13-Aug-15 08:42:12

Thanks HeadDreamer. It's 'technical language' to me only because I haven't worked using it before. Can you tell me where it comes from or what areas of work usually use it because I really need to learn more about how to use it?
Thank you for confirming- I will call it a risk.
I have raised it but they don't seem to take on board the problem. They say 'we'll put this for delivery by x date in the plan' and then when I say that's a random date because if and when that task can be delivered isn't up to me/our company, it's for the third party to decide.. then they look all catsbum about there being 'delays'.
But how can it be 'a delay' when the end date (or any delivery of the result at all) has always been uncertain?
My plan to mitigate the risk is just to keep on lobbying for the result my company wants- but I can't tell my colleagues exactly when I will have achieved what they want by, and ultimately I can't guarantee that in the end the third party organisation will ever agree with my company's ideas. It's (part of) my job to try to make that happen and I can evidence how I will try to do that. But actually all they seem to want to know about is by when is the final task result achieved. Could this scenario be described as a particular 'type' of risk? I wonder if I approach it differently whether they can put risks like this in some other category.

Dateloaf Thu 13-Aug-15 08:50:20

Fusion thank you I really appreciate the posts.
Brilliant- I will look up project management principles to find out more.
Yes at present some of the results they want me to provide are in my view not SMART. Thank you- will use it as a tool to discuss it with them.

Dateloaf Thu 13-Aug-15 08:57:13

Also Fusion hopefully I will find someone approachable soon. It's just such a different set of tools (like Visio and some other package that produces charts for plans) and language 'swim lanes' etc I just feel about 100 years old and massively out of touch at the moment.
My manager seems nice but he manages an enormous team and is rarely even in the country and I feel a bit embarassed to ask him to explain this basic stuff over Skype or whatever.
Anyway thank you for being so kind about it I really appreciate it.

HeadDreamer Thu 13-Aug-15 09:06:09

dateloaf I don't have any project management qualifications so have no idea where those terms come from! But in both sectors I worked in (university research and software) they use terms like that.

The SMART thing is good. We use it to do appraisals. Basically my line mangers will set these goals which should be SMART. And fusion gave really good examples on how you would tackle those goals. In software we would be given the higher level goals and engineers would be expected to break it down themselves. I assume what fusion listed would be acceptable in your field?

gamerwidow Thu 13-Aug-15 09:20:10

These are all project management terms. Workstreams are different areas who need to complete tasks to get to the end goal I.e. Finance, operations, facilities, comms, logistics would be ab example of different work streams. Deliverables are the bits each team needs to in order to get to the end goal. Risks are things that might happen to delay or stop you from doing the things you need to do. These should have mitigations I.e. What actions you can take to reduce the likelihood of these risks happening. Issues are things that you know about that already exist and will cause delays or problems in getting to the goal. You will need to explain how you will manage these. Deliverable dates form a project plan which will aim to pin down when things will happen. Dependencies are tasks that are dependent on other tasks e.g. I can't eat my dinner without cooking it. So eating dinner is dependent on cooking dinner. Delivery dates can move as the project progresses based on how the long the actual vs planned tasks took but you need to constantly evaluate how you are progressing and how much time you are losing so that if other tasks are dependent on yours the staff can replan there time. Hope that helps PRINCE is s good place for you to start with regards to training smile

Dateloaf Thu 13-Aug-15 11:01:04

Thanks Gamerwidow and HeadDreamer. This is brilliant and incredibly helpful.
Ok so.. Can I ask a further question. In my influencing task example. Given that I already know other workstreams at my company are needed to input to (hopefully) the desired end result from the external organisations, shouldn't we all be meeting in the company to talk about how and when we're going to contribute our respective parts to make it (hopefully) happen?
And shouldnt they allow me some time to sound out the other third party orgs to see what the likelihood is of them adopting the position that my company want them to take?
At present someone somewhere in my company is setting my deadlines- problem is nobody with charts seems to to really be able to tell me who- then a planning person comes to me to say you are down on this chart to achieve x by y deadline. Feels like there are quite a few steps missing before we can get to that stage.
Or.. Does everybody all over my company have problems in forcing all of their work to fit in the grid and timescales like this and so it's not stigmatised if we don't meet a made-up deadline, etc?
But that can't be right- at my new company they have RAG colour code systems so they clearly want to minimise 'red' areas in the business. And clearly others do need to plan their work around what colleagues are doing so it's not responsible to let them think these deadlines for producing my fantastic outlines are real. And being new I don't want to be plunged very quickly into 'red'.. Seems my only alternative is constantly saying no all the time which is also awkward being new.

gamerwidow Thu 13-Aug-15 17:40:35

The project plan should be developed by the project manager but with inputs from the work stream leads. I would expect the project plan to be presented as draft for the work stream leads to review and a) find the gaps b) assess if the timelines are feasible. If you think there are tasks missing or the deliverable dates are unrealistic then it is absolutely ok to say so and any experienced project manager would welcome this feed back. It's better to know at the start if there are issues then at the end when it's too late to rework the plan to overcome the problems. If you're being presented the plan as a done deal with no chance to feed back then the project is being run badly.

gamerwidow Thu 13-Aug-15 17:42:34

P.s. I would also think a meeting with the other work streams would be useful.

nulgirl Thu 13-Aug-15 17:50:31

Another way of highlighting the risk without saying no is to raise a dependency. This is a how you would state that you are dependent on the external organisation to agree.

Not sure how long you've been our of the workplace for but these terms are all standard project management which have used for at least the past 20 years. If you are now working on a project then you need to swot up on them because it makes you look rather strange if you claim not to understand this "new" terminology. Have you never worked on a change project before?

Dateloaf Thu 13-Aug-15 22:15:06

Thanks gamer and nul.
This is all really helpful.

There doesn't appear to be much room for my feedback about the tasks that I am being told are required to be completed at the moment, so I wonder if there must be some high level programme managers who are senior to my-level of programme managers? Is that how they structure it in some places? It's quite a big company. I am guessing about that but it would explain why it's not very clear where my deadlines are coming from?
If some very high level people are setting the timeframes and then passing them down to my colleagues to pass on to staff like me to fulfil their request and keep track of progress via a chart, that could account for why my colleagues seem to look at me a bit nonplussed when I keep repeating that on some tasks, it could quite likely be a bit more complicated to achieve x within the timeframe of y which they have given me.

I haven't been out of the workplace for 20 years (though it feels a bit like that sometimes..!) but I haven't worked in a company doing this kind of work/using these methods before, so they are totally new to me.
They hired me as I have specialist knowledge about an area they want to expand their business in, definitely not because I know anything about project management. grin
Thanks again for your thoughts this is all massively helpful and I didn't feel quite so awkward in work today. flowers

HeadDreamer Fri 14-Aug-15 09:34:22

dateloaf I'm not sure how your team is organised. But like gamer says, there should be a project manager and you should be under a team lead. At least in software, the team lead meet with the project manager (there could be multi levels of these) and they negotiate what's to be delivered. It's a absolute nightmare to work with a team lead that didn't understand the field. As they are supposed to estimate the work and agree to realistic deliverables. Do you know who the team lead is in your team? This is the person who you should have a chat with about your concerns. Like gamerwidow says, if feedback from team members aren't taken into account, the project is badly run.

ThinkAboutItTomorrow Fri 14-Aug-15 13:46:18

I can see how it seems a bit arbitrary but presumably getting the external company to agree to x,y,z is a dependency of another element of the project so it makes sense that they want to have an idea of when this will happen by. If you don't agree with there timeline then you need to raise this and give them an alternative - so if it was me I would say, 'I can't guarantee a 'yes' by October but would be happy committing to a yes / no answer from them by December. I will give an update and indicate progress in early october.'

As an example imagine company A wants to launch a new cleaning product 'zap it'. How much they need to manufacture will be dependent on who will sell it - e.g. Tesco agree to stock it = make lots, Tesco says no = make less. Someone is responsible for getting Tesco to say yes, though they obviously can't guarantee this will happen, their job is to be highly persuasive sales reps. But Tesco want to know when it will be launched so they need to be planning the launch - how many bottles and other ingredients to order etc in order to make 'zap it'. There will be a timeline, which will be a changing version based on current information that makes it clear that as long as Tesco say yes by x date, they can have it by y date. This lines up all the tasks related to making and shipping the stuff in a sequence that makes sense. It it are several dependencies - not least the yes / no from Tesco.

Not sure that makes it clearer or not!

Join the discussion

Join the discussion

Registering is free, easy, and means you can join in the discussion, get discounts, win prizes and lots more.

Register now