Approaching projects - Part 7

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.

At my current place, near the start I was tasked with chasing the objectives set by marketing for growth hacking and all that. Turns out the primary consumer base does not care about the better business bureau, nor the unreasonably expensive "secured by norton" mark.

Sure, I could have told them that. I think I did. But experiments exist to vet possibilities. Science isn't about confirming your opinions, it is about observing the real world in hopefully useful ways.

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.

Executing tasks

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.

You have a reputation whether you like it or not. Failing to meet commitments on a consistent basis will take you down. Unfortunately, I went through this while chasing an impossible objective. Or at least, with me alone, it was impossible. At the time, I was an optimist, still in my first job out of university, I thought I could achieve anything. I kept thinking I'd have a solution by the end of the week, for months straight. And then I burned out.

I was put on a performance improvement plan (PIP), squeezed to perform when I had nothing left inside to give. My boss even put a no subject meeting at 8 AM on a monday morning, scheduled at 10 PM on a sunday night, and used that against me to close the PIP. I ignorantly missed the meeting since I got to work at 8:30 and generally meetings start at 9 am.

Essentially, I was told to resign and was given a range of 2 months to set an end date. I chose the last date I could and began to search for new jobs. One month later, I was the top performing team member again. My impossible project was given to someone else, my sense of responsibilities and dread were taken away. And my boss looked at me and wondered why I was doing so well on my way out. He had been told to expect burnt out software engineers to just take the money and do nothing else during their remaining time.

I learned a lot from this experience and I still do upon reflection. Back then I did not know how to realize things were not going according to plan, and I did not realize what I was attempting was experiment after experiment to find a feasible solution.

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.

A few months after I left, my project's sponsor disappeared. The client was bought out by another organization that swiftly switched all locations to another vendor they already contracted with. Two and a half years of my work immediately became vestigial. In a way it hurt.

In another way, good riddance. I was tired working in a basement closet without natural light with a schedule where I'd arrive before the sun came up and leave after the sun went down. The entire place has a reputation for burning people out while instilling incredible amounts of internal evangelism for those that stay in the club. The moment you think you don't fit anymore, you feel an imposter syndrome akin to religious dysphoria.

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.

There is a reputation of project managers being so bored that they ask for status updates every day and it gets annoying. Have some empathy. While some may have nothing else assigned to them, they may be doing their diligence on ensuring the project is being executed smoothly. That said, feel free to tell them to back off and educate them on the point system on tasks. If they don't understand that... good luck. Tell their boss.

As a manager I have observed several instances where a task turned out to be a whole project. Then tasks within that became a project. What I thought would take one week became around three months. I'm still learning. These posts are my method of examining my experiences and identifying where I slipped up.

The most recent example was where a feature's core approach had to be redesigned due to missing a requirement. Once revealed, that requirement was deemed incompatible with the approach developed and tested. Also, the developer's feedback on that task was "it should have been split into three tasks". I'm trying to figure out how to encourage this feedback sooner.

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.

You can succeed! If you can, do work in parallel first, then concurrent work. Satisfy the most impactful deliverables first. Recognize if you're experimenting and get approval for experiments. Watch out for tasks that explode in complexity, more research and design is warranted if they appear.