Taking action and solving problems is fun! But we can't get started taking action right away. We want the end result to be satisfactory, and we are unlikely to get a satisfying result if we jump right in.

Here I present some ideas that may help us to successfully complete our assignments. These are just suggestions and may not work well in your specific situation.

Usually an assignment has at least a refinement phase and an execution phase. In both phases the general idea is to take the next question or action that comes up and get started on that. Finally, there is a review phase, where we review our work or have it reviewed by others. When we are working on assignments with sub-tasks, like a whole project, we will keep going from refinement, to execution, to review, delivery and so on.

We will spend a lot of our time communicating with people. Asking for input, clarification on that input, keeping stakeholders informed and soliciting feedback on our work.

A good first question to ask may be if we are really supposed to do work for the person who gave us the assignment. We don't want to do good work but end up getting reprimanded for it by our manager.

Thinking things over will do wonders for the end result, but only up to a point. Thinking things over is not the same as completing the assignment. Completing something requires taking action. Each action we take will help clarify the assignment. We need to keep evaluating if we need a moment to investigate, or if we should take action based on we know at this moment.

Refinement: planning ahead

First we must make sure there is a written description that we can use as a basis. If it does not yet exist we will make one. The reason we need a written description is that details and nuance matter. Without a description to fall back on and update over time, we will forget or fail to think of important details. It will not only help to clarify what should get done; it will clarify what did and what did not get done over the course of the assignment. We may need to talk to several people to get a complete enough picture.

It is important that the description is clear about what is expected from us, and what isn't. What does an acceptable result or delivery look like? Are we expected to provide support to anyone after we have finished this assignment? Whoever asked for the delivery might expect you to be available for questions and additional work afterwards. Is there a set number of hours listed in the contract? We need to take this type of information in to account when we plan our work.

If the assignment doesn't meet our standards, we should refine it first. Find out what is missing from the story.

Let us look at the description of the assignment. In it, we find sub-tasks and more things we should look at. Maybe there are unfamiliar terms and acronyms or there is a lack of information in a specific area. Make note of these as we read through. Each loose end must be written down to allow us to look in to them at the right time, that way we hope to avoid wasting our time now and in the future. We write down new sub-tasks for these loose ends.

An assignment and each of its sub-tasks:

• Should be specific as to the desired outcome versus the current situation.
• Should have a short but accurate title. This makes it easier to talk about the assignment and avoid misunderstandings.
• Should be very clear on what problems we are and are not solving here.
• Should mention related assignments/tasks to allow for better decisions while working on this one.
• Should be in some way time-boxed, though it may slide out of that time box. To time-box something means to indicate roughly how many hours is okay to spend on something.
• Should mention other topics that might be affected and might need our attention.
• Should mention alternative solutions or workarounds, or a lack of them. Workarounds can be vital in determining our priorities.
• Preferably can be explained easily. This may be hard to achieve but is worth the effort.

When we are done refining we may need to remove unnecessary information. We do this last; if we do this early we don't know enough to decide which parts are not relevant.

Does the assignment fit our current capabilities?

We should also pause to consider that an assignment should be assigned to someone that might have a good chance of completing it to everyone's satisfaction, given the resources and time available. Is that the case here? If not, waste no time and discuss this with the relevant people.

Broadly speaking we can aim for one of these three outcomes:

• Expand the available resources, such as additional assistance becoming available to us.
• Reduce what is being asked of us in the given time frame. For example, the assignment can be split up and assigned among more people or requirements can be dropped.
• Get someone else to pick up the assignment.

Let's get to work

Some sub-tasks can be assigned a block of 25 minutes (like the Pomodoro technique). Others are tasks that have external dependencies. An example of this is when we put in a request for access or information somewhere, and after that we just have to wait it out. These can be picked up in-between other tasks. Don't forget to add a task to remind ourselves of these open tasks. In all likelihood we will need to follow up on these several times before they are resolved. While waiting, we may be able to pick up other tasks. If not, we might look at relevant standards and documents, as well as existing work we have in-house. Make notes of things that might be relevant. It would be great if we could use this waiting time to refine the assignment description, and it's sub-tasks.

Try to stay in the flow of picking up and completing tasks. Keeping it up is the easiest way to get through. There may be delays due to people reviewing our work or because we need to get access to external systems. That is all part of the job. We don't let it get to us.

Keep refining, working on tasks and reviewing

While working on completing our tasks, we keep making notes of any possible ways to split up bigger tasks, or ways to clear up large or vague tasks, and any open questions and loose ends that need to be investigated. We keep switching between refining, taking action and reviewing. We keep refining our backlog of open tasks and evaluating our finished work, preferably with our stakeholders. New insights may lead us to re-work things that we thought were already finished. We keep iterating on our work, building it up to an acceptable delivery.

These ideas are part of what some people call the "agile" way of working. Instead of planning everything ahead and strictly sticking to the original plan, we accept that requirements can change. As long as the changes fit within the timeframe and budget, more on that later.

We may feel that there could be undesirable interactions between the current work and existing activities. Write these thoughts down and follow them up in a timely manner. Don't pick them up when it feels too late already. Here I don't necessarily mean too late in the day, I mean to pick things up soon to make sure they don't become a problem.

In a general sense small open tasks are probably best to handle as soon as possible. Done is done. After that we can get back in to the flow, working on the bigger parts of the assignment where we have less context switching.

Getting un-stuck

Everyone gets stuck at some point, and we are no different. It is good to try to recognize if we are stuck, before we have lost too much time and energy. When we get stuck we can ask for help, but we can also take a walk or try again tomorrow. Whichever feels suitable. We might realize how we can get un-stuck while trying to explain the situation, while taking our walk or while unwinding at home.

In programming circles there is the idea of "rubber duck debugging". The solution to our problem often comes to us while explaining our problem to someone else, and we might as well explain it to a rubber duck. That way we don't bother anyone.

Keep stakeholders informed

The people who depend on our work will need to be kept informed. If we don't keep them informed they may get anxious. Try to find out who needs to be informed, and how often they want to be informed. Perhaps one person wants to have a short chat about our progress on a near daily basis, but another person prefers a more formal bi-weekly meeting.

We also keep the stakeholders informed of any risks we may see coming up.

Manage stakeholders' expectations

We should at all times try to manage expectations. Maybe we have some early results that we are happy to show off. Those early results might give people the idea that we are almost there, even when in reality we are just exploring something that will become a dead end. Getting feedback is great, but don't let stakeholders feel that they are looking at something that is nearly finished.

Some people say that it is better to "under-promise and over-deliver". What they mean is that it is better to promise less than we expect to deliver. That way we may either end up delivering what we promised, or delivering more than we promised. That would be better than delivering less than what we promised.

External dependencies

Sometimes the success of our assignment is dependent on things that are out of our control. In that case we need to make sure that these external dependencies are making progress as well. We don't want to get stuck with our work because other people did not start their part yet.

Potentially problematic external dependencies are one of the types of risks that stakeholders need to be informed about.

We also keep track of people's availability. We ask them if they are available on the days when we need them.

Storage and delivery of our work

Some questions to ask ourselves are:

• In what format are we expected to deliver our work?
• Are we expected to use specific technologies or formats?
• How can we keep it accessible to stakeholders while the work is in progress?
• How can we export our work from the application we are working in?
• Is our work being backed-up? We don't want to lose it all due to a computer failure or lost laptop.

Consider the project's (time) budget

Perhaps we are working on a project with a fixed budget. As a junior employee we are unlikely to have to worry about budgeting. Even so, it is good to know what the status of the project is (are we running out of money or time?) and who is paying for it.

Which budget is this work being paid from? Or is it billed directly to a client? We need to ask the relevant people how many hours we could spend on this at most. We need to plan accordingly, to give us a good chance of ending up with a good deliverable before we run out of budget. Note that we are not asking them how long they think the assignment should take.

We might be asked for a perfect deliverable. If our budget doesn't seem to allow for that, we may need to opt for a merely acceptable deliverable instead. Be sure to discuss this situation with the appropriate stakeholders. This may only become clear when work has already been started.

Sometimes we can avoid some work by spending money. It is easier to take advantage of that if we already know who to ask for permission and how to expense these costs to our organization or client. Any expense is probably coming out of the same budget as our working hours, and will decrease how many hours we can work on this assignment.

Finally, what are the rules for tracking the time or money spent on this assignment? Do we need to use a special code for our timesheet application?

Change requests

What do we do if we are asked to make changes late in the assignment? These changes and additional changes resulting from them may not fit in the budget. We should discuss the risk of failure as soon as possible, and get written approval and acknowledgement of the increased risk of failure before we get started on any changes.

Some tasks are never finished

Be aware that it is possible that people will keep asking us about the work we did for years to come. Perhaps our contribution makes us look like we are responsible for whatever related problems come up. New insights and new requests may come up, and our name is the first that people think of. If we don't have time for this additional work it is best to discuss that with our manager. Note that when requests for work are coming in from people other than our manager we may need to decline and refer these people to our manager. If we don't we may risk getting overloaded with work and deadlines.