Approaching projects - Part 7- 14 min read - Text Only
Do you have a project, a skill, a goal you'd like to complete or progress? Are you on your own, lacking leadership and structure, or could use more of it for yourself and your team? Here's what I've discovered works for me as a solo software developer and later as an engineering manager. This is a series of posts, the next post part 8 on cultivating the plan comes next.
In the last post Approaching projects - Part 6, I described documenting a plan with a set of tasks. This post will focus on documenting the steps that will be executed.
Throughout this series of posts I will be using this user story: As a person with money, I want a custom computer desk to fit in a weird spot in my home. With the chosen solution: Build the desk myself.
Executing the plan
At this point you're pretty sure on the solution and you have tasks documented for each step to achieve it.
Or at least, you think the solution is sound. If the project includes vetting the approach (as recommended within a nested project), be prepared to design another if the experiment proves infeasible. You may need to negotiate more resources if an experiment falls through. Communicate the possibility early on.
There's a reason why frontend changes are called experiments. Should this button be bigger, moved this way, colored another way? Is the new GUI more effective, or less? Changes to user engagement and conversion start with a theory, a way to change something tha affects it, and a means to measure the impact. Projects that exist to prove an approach has merit are similar.
Executing your project plan will require an open mind. Unlike manufacturing, where every step...
- Has been done before
- Has been completed before
- Has been integrated between other steps
- Has been completed between other steps
- Reliably utilizes a bounded set of resources
- Can be trained to perform or automated in isolation
- Can be repeated without creative direction
Development plans require creative direction in a dynamic environment. Watch for signs of risk and be prepared to address or revise.
Ordering and Prioritization
Assuming the majority of your tasks are derived from the plan model as described in part 5, and you can reason about the directed acyclic graph of dependencies, the ordering is easy. Double check that the milestones are in a sensible order, that each milestone is sorted by impact and return, then insert depended-upon milestones between. For example, there's no sense in routing and sanding the table top before assembling the planks of wood into a table top. For each milestone and its attached deliverables, take the associated steps to produce each deliverable.
At a high level, I can see that two project-scale deliverables can be done concurrently (that is, different work that can be done at the same time). So, if I had a companion on this project, we could both work on different deliverables (building the frame and the table top) and join on any final tasks or participate in other projects until concurrent work can be done again.
Another thing to consider is parallel work (that is, work similar in nature that can be done by multiple individuals).
Knowing this, after the frame has been designed and resources are gathered for both projects, I could have two resources work on plank preparation, then one continues tasks from the table top tasks and the other on the frame tasks.
You may also be able to provide the stakeholder with a more confident roadmap and timeline at this point.
In documenting a plan, I went over what makes a good task. Apart from doing what the task says to do, the most important thing to do is communicate progress and even more so to communicate surprise and changes in scope. If you're on a committed schedule it is your responsibility to communicate risk concerning the schedule's delivery to the stakeholder. Next is reacting to tasks that do not go as planned.
When you discover your plan's premise is not working out, consider an experiment only after communicating the option to the stakeholder. Experiments are risky to your reputation, especially if you do them without asking and they fail.
Gaps will be identified in complexity, detail, requirements, and / or scope. If you're doing the tasks, call them out, communicate them to the peers and project manager or project owner. The project manager or project owner will then communicate to the stakeholder on a routine basis. If you're the project manager be on the look out for tasks that go over 1.5-2x in time.
Rewriting tasks, splitting tasks, removing unnecessary tasks will come in the next post.
The main takeaways of this post are:
- Experiments may be successful or unsuccessful
- Recognize when you're doing an experiment
- Be open to changes in a project after the plan has been produced
- Order tasks by impact and dependencies
- Proactively gauge change in complexity, detail, requirements, and scope
- Communicate status of tasks and changes in complexity, detail, requirements, and scope on tasks
This post is the seventh of the series, part 8 on cultivating the plan comes next.