There’s two ways for an assignment to come to an end: either the budget has run out or the task has been completed. The budget case asks for a handover. For whatever I have been doing will be carried on by the regular employees and they must be brought up to speed. That’s a nice enough task, rendering account of one’s activities and doing a bit of educational work. But in the completion case, a real gem may be hidden: the opportunity to look back and write a closure report.
This month, I got this opportunity. The assignment, as assignments go, had been clear enough considered from a suitable distance, but, under scrutiny, appeared riddled with mystery. But that’s an uncharitable way of putting it. It’s fairer to say that whoever wrote it had a clear picture of what the organisation needed but did not stop to think about – let’s call it the modalities.
And there’s always plenty of them, of those nasty modalities. How should this task be embedded in the organisation? Should it be part of a project? If so, which one? Should it be assigned a project of its own? Must it compete for budget and resources like every other project, or is it so important that these should be secured up front? In which case, how can we make this happen? On the other hand, if it should be a competing project, what happens to the assignment if it loses the battle?
Or is all this project talk irrelevant because the task is so urgent that it should be carried out straight away? But if it is outside of any project structure, who will make sure that it is resourced? Who will defend its priority when other tasks come along claiming even more urgency?
This month, I got this opportunity. The assignment, as assignments go, had been clear enough considered from a suitable distance, but, under scrutiny, appeared riddled with mystery. But that’s an uncharitable way of putting it. It’s fairer to say that whoever wrote it had a clear picture of what the organisation needed but did not stop to think about – let’s call it the modalities.
And there’s always plenty of them, of those nasty modalities. How should this task be embedded in the organisation? Should it be part of a project? If so, which one? Should it be assigned a project of its own? Must it compete for budget and resources like every other project, or is it so important that these should be secured up front? In which case, how can we make this happen? On the other hand, if it should be a competing project, what happens to the assignment if it loses the battle?
Or is all this project talk irrelevant because the task is so urgent that it should be carried out straight away? But if it is outside of any project structure, who will make sure that it is resourced? Who will defend its priority when other tasks come along claiming even more urgency?
To complicate matters even further, this organisational maze was adorned with a few confusing signposts. The assignment mentioned being ‘ready in time’. It wasn’t obvious, though, what ‘ready’ should look like and when ‘in time’ would be. The first deliverable was dubbed ‘minimum viable product’. This wording suggested a tool of sorts, but in fact was used to refer to a rather disparate set of products, procedures, features and measurements, which did not even have a deadline in common. Thus, terminology became a plentiful source of confusion in its own right.
Making sense of difficulties like this – which, when you come across them, present themselves rather diffusely as hindrance, lack of cooperation, feeling bogged down – definitely is easier in retrospect. It is a good thing to be given the opportunity to analyse your own project’s history. The client appreciated the insights very much – and so did I.
Making sense of difficulties like this – which, when you come across them, present themselves rather diffusely as hindrance, lack of cooperation, feeling bogged down – definitely is easier in retrospect. It is a good thing to be given the opportunity to analyse your own project’s history. The client appreciated the insights very much – and so did I.
There’s two ways for an assignment to come to an end: either the budget has run out or the task has been completed. The budget case asks for a handover. For whatever I have been doing will be carried on by the regular employees and they must be brought up to speed. That’s a nice enough task, rendering account of one’s activities and doing a bit of educational work. But in the completion case, a real gem may be hidden: the opportunity to look back and write a closure report.
This month, I got this opportunity. The assignment, as assignments go, had been clear enough considered from a suitable distance, but, under scrutiny, appeared riddled with mystery. But that’s an uncharitable way of putting it. It’s fairer to say that whoever wrote it had a clear picture of what the organisation needed but did not stop to think about – let’s call it the modalities.
And there’s always plenty of them, of those nasty modalities. How should this task be embedded in the organisation? Should it be part of a project? If so, which one? Should it be assigned a project of its own? Must it compete for budget and resources like every other project, or is it so important that these should be secured up front? In which case, how can we make this happen? On the other hand, if it should be a competing project, what happens to the assignment if it loses the battle?
Or is all this project talk irrelevant because the task is so urgent that it should be carried out straight away? But if it is outside of any project structure, who will make sure that it is resourced? Who will defend its priority when other tasks come along claiming even more urgency?
To complicate matters even further, this organisational maze was adorned with a few confusing signposts. The assignment mentioned being ‘ready in time’. It wasn’t obvious, though, what ‘ready’ should look like and when ‘in time’ would be. The first deliverable was dubbed ‘minimum viable product’. This wording suggested a tool of sorts, but in fact was used to refer to a rather disparate set of products, procedures, features and measurements, which did not even have a deadline in common. Thus, terminology became a plentiful source of confusion in its own right.
Making sense of difficulties like this – which, when you come across them, present themselves rather diffusely as hindrance, lack of cooperation, feeling bogged down – definitely is easier in retrospect. It is a good thing to be given the opportunity to analyse your own project’s history. The client appreciated the insights very much – and so did I.
This month, I got this opportunity. The assignment, as assignments go, had been clear enough considered from a suitable distance, but, under scrutiny, appeared riddled with mystery. But that’s an uncharitable way of putting it. It’s fairer to say that whoever wrote it had a clear picture of what the organisation needed but did not stop to think about – let’s call it the modalities.
And there’s always plenty of them, of those nasty modalities. How should this task be embedded in the organisation? Should it be part of a project? If so, which one? Should it be assigned a project of its own? Must it compete for budget and resources like every other project, or is it so important that these should be secured up front? In which case, how can we make this happen? On the other hand, if it should be a competing project, what happens to the assignment if it loses the battle?
Or is all this project talk irrelevant because the task is so urgent that it should be carried out straight away? But if it is outside of any project structure, who will make sure that it is resourced? Who will defend its priority when other tasks come along claiming even more urgency?
To complicate matters even further, this organisational maze was adorned with a few confusing signposts. The assignment mentioned being ‘ready in time’. It wasn’t obvious, though, what ‘ready’ should look like and when ‘in time’ would be. The first deliverable was dubbed ‘minimum viable product’. This wording suggested a tool of sorts, but in fact was used to refer to a rather disparate set of products, procedures, features and measurements, which did not even have a deadline in common. Thus, terminology became a plentiful source of confusion in its own right.
Making sense of difficulties like this – which, when you come across them, present themselves rather diffusely as hindrance, lack of cooperation, feeling bogged down – definitely is easier in retrospect. It is a good thing to be given the opportunity to analyse your own project’s history. The client appreciated the insights very much – and so did I.