A project manager (PM) is the person who knows what’s supposed to be happening, what actually is happening, who is making it happen and who isn’t, and when it’s all supposed to be done. If it’s not getting done, they know why and what levers to pull to deliver the next most important thing — all within the timeline and budget, pretty please!

In an earlier lifetime, when I had hair and didn’t have kids, I enjoyed traveling to locations off the beaten path. A jungle in Indonesia, mountains and deserts in Jordan and Morocco, and remote villages in Ghana were adventures rife with unknowns. I was willing to undertake these risks because I was traveling solo, only risking my own time and well-being.

Since those days of my youth, I have organized and led many trips with other travelers. I employ guides and fixers now, even in countries I have been to before. Why? I want someone else to handle all the daily details so I can ensure that my guests are having the experience they were looking forward to.

When starting a new project, our clients want a guide and fixer to recommend all the things that should be done along the way to steer the project away from trouble and ensure that the end result meets the goal. If I’m doing my job well, the project owner and stakeholders should be able to enjoy the ride, knowing that the day-to-day details are being taken care of.

In my years with MartianCraft, I have worked with a wide variety of clients — from a massive US retailer to a private education institution, from bootstrapped entrepreneurs to series A, B, and C startups, from a medical device manufacturer to a Fortune 100 global technology provider. Some projects are short, completed in a matter of months. Many last for years. That broad and varied experience enables me to craft a custom playbook tailored to the specifics of each project.

Defining Client and Project Success

One thing is constant for any project and any client, though: Well-defined measures of success are the keystone everything else is built around.

Once the sales process is complete and a project is ready to begin, I’m thinking of that idea as its own business. At this step, I want to know both the technical goals for the software and the market or business case it needs to serve. We want to answer mission critical issues like the project’s purpose, design needs, budget and funding, and timeline. We need to take into account technical considerations, functional requirements, the hardware needed to test on and deploy to, and the release strategy. The details that come out of this step become the foundation of the project plan.

For startups and short-term engagements, the technical team and I often guide the big idea as well. We are the first line of feasibility, where the idea meets working code. Our challenge is to find the best design and technical solutions as quickly as possible. No shortcuts are allowed here, because this work usually becomes the foundation for an entire business. What we find to be possible could limit the original scope, but more often I have seen it profoundly broaden the vision for the idea. I never get tired of hearing a project owner say, “Oh, that’s awesome! I didn’t know we could do that!” when we demonstrate our concepts for the software.

Projects for large enterprises may require working with legacy systems, databases, and processes. Just as often, though, we are brought in to build something totally new, sometimes even software that will take the business in a new direction. My job as project manager is to know which sort of project path we are on. Does this one require a quick turnaround on R&D? Are we capturing a new market segment? Do we need to integrate with large legacy systems? It could even be a bit of all of the above.

Beyond the checklist of necessary elements, I want to know what your hopes and dreams are for the project. Once the idea is out of its infancy, how do you see it growing and living in the world? I also like to revisit this conversation after major milestones are reached. Taking a moment to lift our eyes from the day to day and remember why we’re on this path and where it’s going renews vision and excitement for the whole project team.

People and Communication

After defining success, the next critical element is understanding the people who are doing the work. What are they good at? Where are they going to need help? Are all the talents we’ll need to deliver the mission critical goals we just defined available? What will I need a strong technical lead to keep me informed on? With these basic questions answered, I can now build a project plan.

The project plan helps us visualize who does what by when. I capture the core project tasks to the best of my understanding, then I review the plan with everyone who will be responsible to deliver that work. Together, we add more information from each involved role, agree on the scope, and estimate the time to complete the work. This can happen in a 30-minute meeting for small projects. It may take a week for larger projects involving many team members spread across time zones.

What does the project plan have to do with the people? By creating the plan together, we create a contract among the team that will be communicated to client stakeholders as well as the development team, extended partners, vendors, and contractors. We become accountable to each other. I find this process especially necessary with fully remote teams to build a sense of unity: that we are working collaboratively toward deliverables we all agreed on, according to a timeline we created together.

Weekly Communication

Once a project is underway, my focus becomes communication. It’s essential for me to keep project owners informed, which I do with a weekly written status report and at least one weekly call to address questions and discuss potential changes. Beyond these regular communications, I pull project owners in for decisions as needed and alert them to any new risks that arise, along with our contingency plans to handle them. Waterfall methodology has its place, but the vast majority of software development requires this kind of constant communication and agile process.

If I were your exotic travel fixer, this is the evening when I would brief you for the next day saying, “The bridge is out on that path we planned for tomorrow and there are alligators in the river. We either need to devise a plan to cross this river full of alligators or take a different route that I’ve scoped out for us”.

Managing the Details

At the top of my mind daily is the productivity of everyone delivering the work. The team needs a coach deploying the right talent, setting the strategy, and adjusting the game plan. Most of all, they need uninterrupted time to do the actual work. To give them that, I clear their paths by answering common questions such as:

• How exactly should this thing I’m working on behave or integrate to drive the overall business goals?
• I still need X to stay on my timeline — that’s being taken care of, right?
• Can we set a meeting to get questions answered or decisions made about the next phase of work we will need to deliver?
• What should I be working on next?

Administrivia is the death of productivity. Our most valuable assets on a project are the people delivering the work. When I stay on top of the daily minutiae to proactively provide those answers, I keep skilled people from ever having to ask those questions, and that keeps the project healthy and proceeding successfully.

Process and Admin

In the fall of 2021, I took a group of cyclists on a trip in Tuscany. We had two guides to drive vehicles, mark the route, look after the bikes, handle hotel and dinner reservations, and show us their favorite parts of the region. We saw Antonio and Jago infrequently during the day, and yet every day of the trip went off without a hitch. We began joking that they spent most of the day napping, to which we received a swift rebuke that they were spending the time heading off problems and preparing for the coming day. The logistics were being handled so well that we didn’t even think about how they were getting done.

Some things should happen in the background and never receive a great deal of attention, such as meeting facilitation, preparing presentations, progress tracking, status reporting, work breakdown and assigning tasks to developers, keeping everyone accountable to the project plan, budget planning, contingency planning, QA, rollout planning, staffing, and documentation. These activities are what take up our “nap time” as your project travel guides.

Of those background efforts, it is worth expanding on QA and rollout planning. While I try to minimize the joint effort those take up, they are very important.

QA is essential. We’re not going to release a product with bugs and critical errors. I get it; testing sessions aren’t exactly exciting. But successful project completion means verifying that the product is error-free and meets client expectations. We often work with external contractors dedicated to QA and user acceptance testing for large clients. For startups on a tighter budget, we might facilitate beta releases to a small group of family and friends recruited to test and give feedback. In a few cases, it has been me, the client, and a database engineer working through test cases on my own QA plan spreadsheet and verifying the activity as it flows through a backend server. I know how to have a good time; yes, I do!

A rollout plan can have many wrinkles and requires close coordination with the development team to ensure everything is in place and ready to go live. The marketing team may need help from our designers to prep images for the App Store, the client’s website, internal training, and other marketing materials. It doesn’t need to be complicated, but overlooking launch planning can be disastrous. In fact, if you look back at the mission critical goals I defined in the project plan, the release strategy was one of the items I included in the project plan from the very start.

Artifacts

As a contracting company, MartianCraft fulfills one step in the lifecycle of a business or larger product. We prepare a code repo, documentation, and some kind of “what we did here” notes to hand off to the next person or team, who will maintain or build onto what we are delivering. Most of this happens organically, thanks to our policies around regular code check-in and commenting and documenting within our code repos. But occasionally I do get the chance to blast my favorite music for an afternoon while writing up a full functional requirements spec and business case docs to pass back to a product owner before we wrap up a client engagement.

Loose Ends

All the developers and designers are assigned their things to work on, and there are no fires to put out today. I’m going to take a walk and think about problems, needs, or opportunities coming up that weren’t accounted for in the project plan. I try to put myself in the shoes of the project owner and think about what they will need next or what would make their life easier.

The nice thing about project-based work is that there is always an end point. With software projects, just like travel experiences, the destination is always a reason to celebrate. New territories were explored, new lessons were learned, everyone grew a little bit from the experience — and we’re ready to take on something even bigger the next time.