Four Pillars of a Successful Development Project

Or, How I Learned to Stop Worrying and Love a Detailed Meeting Outline

As a technical project manager turned full stack JavaScript developer, I have a unique understanding of the complexities of a development project and the many and varied ways one can succeed or fail. Different PMs apply different management methods to different projects based on their experience and the needs of the client. Some projects are handled the old fashioned way, following a strict waterfall schedule with deliverable deadlines and features set from the start. Others are more agile, with features being regularly re-prioritized based on user feedback and the clients’ changing needs. I’ve seen projects succeed and fail under a variety of management methods and processes for many different reasons. That’s all well and good. HOWEVER…

This post isn’t about all that.

In this post, I want to go a little deeper than method or process. I’d like to talk about philosophy. Specifically, the philosophy that transcends method and applies to all your projects, regardless of who’s involved or how they’re run.

Over the course of my 10+ years in this industry I’ve developed a set of pretty straightforward principles that I use to guide a technical project. These are my “pillars of success”, so to speak, and I strive to apply them in every project I take on. They’ve helped me manage projects big and small, as part of a team or as a sole freelancer. They’ve also helped me when I wasn’t in a management position and was simply a part of a larger whole. I hope you find them helpful!

1. Preparation

My first and most import project pillar is preparation. (Second is alliteration, apparently.). When I’m beginning a project I try to front-load it with as many planning meetings as I can, from SOW planning with biz dev, to the general project kick-off with the client, to the technical kick-off with developers, dev-ops, and QA. These meetings may sometimes seem like overkill, but they are necessary for laying the foundation for understanding project milestones and setting the team up to for success.

By answering questions and working out as many details at the beginning of a project as possible, we avoid coding blindly and having to backtrack and rework components or features. Planning and documenting upfront also helps us set client expectations appropriately and more easily handoff tasks and project assets between team members.

2. Transparency*

I strive for radical transparency on all my projects. This means being proactively communicative and keeping appropriate stakeholders apprised of one’s progress at all times.

Transparency is a tricky idea to throw around because it can mean different things to different people. For me, transparency comes in many forms: being vocal on Slack or over email about when you will be working and when you’re unavailable; writing clear sprint or kanban tickets and keeping them in the appropriate progress columns; coming to and fully participating in meetings and stand-ups; letting PMs and other team members know when you’re blocked on a task; asking for help when you’re stuck; and much more.

The above are all good examples of transparency; however, they can still leave room for misunderstanding. That’s where the radical part comes in. Radical transparency happens when you pair good communication with relevant and necessary context. For instance, when giving an update in a stand-up, we talk about what we just finished working on, what we’re currently working on, and what we plan on working on next. This format keeps stand-ups relatively short, but still gives everyone a good idea of who’s doing what so there’s no cross-work.

Another example is writing clear reproduction steps and attaching screenshots when writing bug reports. Sometimes a bug or error that seems obvious to you will be meaningless to the person to whom it’s assigned. Repro steps, device/environment info, and screenshots help contextualize the bug in a way that lets anyone read the issue and understand it without having to come back to you with more questions.

*Everything in the transparency section is meant to be applied internally. While I also believe in radical transparency with the client, it’s still possible to overshare and needlessly worry them, and that’s a whole other blog post.

3. Modularity

My third pillar of project success is modularity. Well-contextualized design systems and component diagrams help developers break down work into the smallest possible chunks, making iteration easier and rework less likely.

Building out an app modularly also help PMs and producers explain the scope of a feature to the client by offering all the different moving parts involved in that feature. For instance, a client might view a request for a login form as a relatively simple ask. It’s just an HTML form, right? How hard could it be? What component breakdowns help you do is show what’s actually involved in that request, from user authentication (is this a third-party API call?), to data storage (where is the user info being held?), to higher-order functions (how will you restrict certain page access to users that aren’t logged in?). Discussing these components and asking these questions help the client understand everything that goes into “just adding a form”.

For site and app redesign projects, rolling out changes modularly helps reduce the amount of acquired knowledge users must gain (or re-gain!) in order to continue to use the system they know and love. In other words, modular roll-outs means a user isn’t presented with an entirely different UX or design the next time they update your app.

Finally, having clear and up-to-date design systems and component diagrams in place makes on-boarding new devs a lot easier. ‘Nuff said!

4. Ownership

Finally, I encourage all stakeholders (including the client!) to take ownership of their part of the development project. This means educating yourself on something that you’re not familiar with if it’s an integral part of the project. It means taking notes during meetings and speaking up if your notes don’t match what’s being discussed in a stand-up or future meeting. It means wireframing full pages and individual UI components, even if you’re not a designer, so that team members have an idea of what you’re building. It means writing and updating component diagrams and READMEs.

Most importantly, ownership means creating a deliverable that is useful, decipherable, and has obvious intent, no matter how small the scope. Current or future team members should be able to review your deliverable and, without any input from you, understand why you made it and how it can help them.

Of course, these are just a few of my favorite pillars of a successful development project. There are many others that are equally indispensable. What are some of the principles that you stick to in a project? Leave a comment and tell me all about ’em!

Thanks for reading, and until next time, here codes nothing!

Feature Photo by NESA by Makers on Unsplash