Small scale project management

I’ve been there a lot having worked for a long time as sole developer on projects. I’ve not been in a position to need to deal with the issues in a while though, so not sure how well my suggestions would turn out in practise.

My expectation would be that the problem is less of a “what do we do”, but more in “how consistently do we do it”. Project management takes time and as developers we’re not that used to manage projects. We much rather deal with the work than trying to line up work in an orderly fashion. So imo the first step is acknowledging the fact that dealing with those things can’t happen “on the side”. It’s work that needs to happen like any other work and prevents you from doing development at the same time.

My suggestion would be starting with the smallest amount of process. Gather feedback (not act on it yet) and bring it together to a single meeting/timeslot (choose some fixed cadance and stick to it), where feedback is aggregated and sorted and at best prioritised with the client. Try to get a single person of the client to own prioritization. I like to compare this “upkeep work” to a library. Libraries only stay orderly by having a shared drop off point and then a few select people putting books back in order to a maintained system. Then everyone can continue to enjoy the orderly fashion of finding most books.

As for reading material: I really liked shape up. It’s probably too much process for your setup, but the ideas can be implemented with less process as well.

Hello Linus,

I’ve been freelancing either solo or with a few people forming tiny ephemeral teams for a long time now and have been in this situation a few times.

When this has been solved for me (because being an human process problem, sometimes it does not get solved), it boiled down to these things :

• Frequent collaboration and workshops with the client, if possible, on-site : this solves the lack of implication on the client’s side by not letting time pass by. The busiest the client industry, the easier for them to let the project slip. The project must not slip.
• Designation at the client of a clear project coordinator who understands the goals, stakes and specifications, sifts through internal feedback, filters, and prioritizes it. This solves the “design by commitee” issue that can arise in some organizations.

Basically, the belief that the project is a team effort (the team being you and them) must be established and a shared culture. Asking for new features all the time is anti-team effort.

Some other companies were very good at giving me / my small team a very clear spec of what they needed, and we only needed a launch meeting, a “first delivery” meeting, a feedback phase and a final delivery meeting. But that’s the less frequent situation.

In the situation you are describing, the client forming a small, project-focused team that could make feedback loop quicker, with a single person tasked with being a source of truth, helps a lot.

Once, when a project was really slipping despite my very frequent e-mails and calls, I just took the cost of an unplanned trip and told them I’d go on-site for a week and we’d put everything back on track. Nobody asked me for that, but we were able to wrap it up.

Sometimes organizations are not able to take decisions in their own interest, even if the project itself is still of interest. Sometimes, a one-year-of-work project can happen in three months when interests and personalities align. Sometimes, unclear hierarchies and scopes can spread a one-month effort over three years of you trying to get people collaborating…

Props to you for being a small shop, it’s very interesting to read about other’s experiences.

Edit : thinking about it more, it’s all about getting to a shared truth on what the project really is. The method to get there can vary. I like workshops & short feedback cycles a lot but YMMV.

This hits home! The truth is that I start most days with communicating with some of the stakeholders. At the start there were many questions from our part to people in the organisation. Now it’s the other way around: they have requests and questions for us. which all have to recorded somehow (or not, but that has to be a conscious decision, and be communicated). It does introduce a lot of stress from my part, because it doesn’t feel very productive (although I know it really is time well spent).

Until now we took it on ourselves to prioritize much of the work. But one designated person that coordinates from their perspective is really required. We can’t defend many of the choices we made, because we simply are not knowledgeable enough about how things work in practice.

We’re actually creating software to support the operations of a (very niche) library. So I can work with that analogy

This belief is growing. But it wasn’t at the start. Putting things in production really helps creating a shared responsibility somehow.

Great point! I guess we’re so far removed from our client, that they don’t see the trouble we’re having with this constant stream of (allegedly) urgent work. We on the other hand don’t see their struggle, when things we made are making some things harder in their day-to-day worklife.

Short feedback cycles are a pet peeve of mine! It applies on so many levels.

@Lucassifoni Could you give an example of a good format for a workshop in this context?

One thing I learned from my career, and it was true 99% of the time – nothing is as urgent as people claim.

The good way forward is to ask for feature / requests freeze for you to be able to deliver what you committed to. Everything else has to come after. Or if they really are like “but but but, just these 137 things, won’t take long right?” then just increase rates or agreed upon final sum.

I am not saying you should antagonize your customers but it seems to me they are crossing lines and you should stand up for yourself and the team. Have them commit to a feature list and not add anything for a while and take it from there.

Their “struggle” very often can be likened to that of a kid in a candy store, namely they don’t know where to start from. Once people witness the computer-reality-bending powers of programmers they start asking for anything and everything.

And stick to it, even when you feel it is unnecessary from time to time. A badly followed process is worse than no process.

There are many web based project management tools out there; try a few, pick one, and go to the lowest pay tier. Paying for something will enforce the habit mentally.

Somebody needs to be responsible for triaging / deduplicating / prioritizing this feedback, or else your effective team size is three people + everybody sending feedback.

In my experience this is the MOST DANGEROUS time in a rewrite; it’s very easy to skip the hard & unimpressive work of replacing the last bits of the old system in favor of shipping shiny new features.

But until you actually remove the old app, all you’ve accomplished is increasing the complexity of the system (by adding a second copy)!

Your team is small enough that I’d skip the lists and ask a single question: “what is the MOST IMPORTANT THING to deliver right away?”. Between replacing the last of the old system and whatever they pick, that should be more than sufficient to keep your small team busy.

This is a gem of an advice.

We (2 folks) developed mathocrat and had two huge sections in readme - features and bugs .

We used to maintain/ update that almost every day.

An one section where all the uncategorised things go.

Point is - we kept following a simple process. And it helped us gain focus when we felt lost.

Even today, that readme has many issues we will never address. Or many features which don’t make sense today.

I agree!

When we started this was actually our the most important guideline for deciding on tasks and priorities: what do we need to build to phase out the old system (and literally unplug that server and it’s license costs), and have parity with the existing features. But somehow this has faded away as the leading guideline. One of the factors that got in the way is that the old application was a client-server Progress application, with a very arcane GUI (with F1, F2, F3, etc. having prominent functionality). We built a Phoenix LiveView application. So just building towards parity with the old system was very difficult (and would probably not be a good idea, since it’s a completely new paradigm).

Hi !
By “workshops” I mean a kind of meeting focused on solving a feature, that should very quickly be followed by an usable prototype. Or, if a prototype has already been produced, a workshop about it should make it (almost) definitive.

For that, I try to gather :

• 2 users of the feature that will be impacted in their daily work
• 1 more user that also follows the progress of broader project
• 1 person higher in the hierarchy that also follows the broader business goals

This works in a situation where higher ups know that they maybe do not fully grasp hands-on work anymore, and daily users of the software know that they maybe do not have the full picture. They work together.

One thing I would try to avoid at all costs today is a budget expansion, because that also means time expansion. IMO It is better to deliver something close, but adjusted, to the initial scope with limited resources than to deliver a huge lot more than the initial scope with resources that never stop renewing.

Maybe try to delay feature requests for a second project phase, with a second contract, and a bit of sink-in time before ?

Good luck for your project

Edit : I should disclose that I’m transitioning to SAAS after years of doing this, mostly to focus on a longer-term product, but also because of the kind of situation that you describe. I haven’t been able to solve it permanently.

One thing I have learned over and over again is to be onsite and personally talk to the people using that software. Especially the first few hours/ days. Often enough people have no proper onboarding and get very frustrated with the new app. Talking on person can really help reducing stress in the long run.