Small scale project management

Chat / Discussions
,
1

I’d like to seek advice about small scale project management. Although this isn’t Elixir specific, I’m quite confident this is a good place to start a discussion about it, since Elixir is such a good fit for small cross-functional teams that want to get things done with fewer resources.

We are a team of two developers and one person who’s more customer faced but only involved part-time (with other roles and duties in our company). We’ve ventured into a software project for a client that has little experience in custom software development. It’s been a very educational journey until now. We’ve been working on the project almost fulltime for more than a year now. The software is a rewrite of an existing application. But of course they are dreaming up a lot of new features too, so it’s not only replacing the old with something new. The specifics are not really important.
Extracting the current feature set, and the new wishes has been a challenge. Knowledge is distributed over several people (not too many, but still, not everybody knows how to share that knowledge in a structured way). It took way more time than I had anticipated, and I think about half of the time we spent analysing and making sure we understood how everything fit together. Unfortunately, there was no one at the client company that had the role of product owner or product manager (or whatever the name of the role, I’m not really knowledgeable in those terms).
I don’t think that was necessarily bad, but I could imagine a smoother process if someone would have stood up and was the liaison for all functional issues. I think we did great, given the circumstances.

But now, more than a year later, we went into production. Not with the full feature set, but with a subset that is good enough to strangle a big part of the old system. I really stressed that going into production rather earlier than later was necessary. And I was right: now that sh*t hit the fan (read: they actually started using the software), a lot of feedback began poring in. Although we always shared our work transparently on an acceptance environment, with real data, that never led to the same feedback we receive now, when they really are forced to use the system. I guess I’m not surprising anyone :slight_smile:

A lot of words, just to set the scene, sorry. At this point, we’re really getting a lot of input and feedback from a lot of different people. It’s like an avalanche, and we still have to add new features too. I’m often overwhelmed by all the unstructured input that’s coming at us. At several points in time we’ve tried to take stock of which features are on the radar. We also tried to involve the client into picking priorities (“if we do this first, then that will have to wait”), so we were sure to be working on the highest priority tasks first. It resulted in a bunch of lists and kanban boards that were soon losing their value in providing insight for all involved parties. None of the attempts stuck.

I’m really interested in how people working in small teams (it can’t get smaller than a team of two, can it?) analyse, plan and coordinate their work with clients that don’t really know what it takes to be a good customer for custom-built software (specifying clear features, short feedback loops, facilitating communication with the end-user, etc.). Don’t get me wrong, I really like the small scale of it all, but we could really benefit from better processes. I used to work in larger agile teams, where roles and processes were all set up. I didn’t have to think about those things (nor did I really want to, at that time). I also don’t believe in all the agile fairy-dust that’s being sprinkled on large corporate software projects. I believe that every project is unique, and that there’s no one-fits-all solution.

I’m curious if any of you have good experiences to share, that apply to these small scale scenarios. Maybe stories about how teams got through these chaotic times by introducing some kinds of collaboration, or other kinds of turning points. Maybe good books on the topic? Or any other anecdotes (ideally with a positive twist at the end). I like to learn about what worked, and what didn’t in those situations. I feel like a lot has to do with communication and clearer processes. Enlighten me! :bulb:

6 Likes
2

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.

9 Likes
3

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.

6 Likes
4

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 :slight_smile:

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

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?

5

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.

3 Likes
6

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.

6 Likes
7

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.

7 Likes
8

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.

2 Likes
9

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).

10

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 :slight_smile:

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.

2 Likes
11

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.

3 Likes
12

Yeah, you learn more in a half-day onsite than in weeks of e-mail exchanges.

Sometimes people keep a frustration because writing a proper e-mail with details is a lot of effort.
But I also notice a lot of “we didn’t want to bother you” for changes that take 30 seconds and are perceived as deep magic.

1 Like
13

I don’t know how applicable this might be to your particular circumstance, but just wanted to comment on this more basic premise of providing useful functionality. (This is not necessarily to be critical of your particular case, but to highlight some aspects of the dynamics that arise in these types of scenarios.)

I’ve worked in VFX pipelines, and also helped scientists and others with domain expertise with their issues. In either case, there are lots of things that are not known ahead of time, and the work changes all the time too. The most important thing is to be sitting there next to the person doing the work, or even bettter, for it to be your job to do some part of what they’re doing, so that you experience the actual pain points of their work. It is very easy to misunderstand what someone is doing, even if they give you as detailed a description as they possibly can (which of course you should be grateful for, because you are now a burden, and taking time from them being able to do their work), and especially if the work is 1) not something completely standardized 2) has frequent changes 3) has actual complexity not because of the need to deal with some over-engineered system, but because real world scenarios have complexity. In all likelihood, they might not quite understand the friction points which influence behavior in this type of time-constrained work, which tend to be harder to verbalize than the “big stuff.” They’ll certainly tell you about the big obvious things, but the thing is, a lot of those big obvious things are not what count in day-to-day circumstances of carrying out the work.

The invisible small friction points that people think they can work around are what wind up bringing projects to their knees, where you wind up with complex, rule-oriented systems, some supposedly productivity-enhancing thing that “automates” the wrong thing, or adding in constraints that kill people’s ability to carry out basic work tasks.

Beyond VFX, some of these issues have become so ingrained in the systems that have resulted from the era of “online advertising-driven tool development,” that it’s even hard to see the issue at hand. A lot of systems are thinly disguised means of generating profits for cloud computing businesses, or data capture operations. So some of what are described as “best practices” are actually funneling people towards serving those ends. The “helpful functionality” aspect takes a back seat and is out-of-mind as a primary concern. But if you want to actually help people with what they need done, it’s hard to get around the fact that you need to actually experience the world from their point of view.

An ideal situation to be most effective at actually helping would be… to join the company and work as an employee, who can see and experience what they need. Barring that, just work on small bits of functionality that actually help them to do specific tasks rather than on “shipping an applicaton” that they might just set aside and never use, the moment it makes anything they actually need to do harder than it was before.

Before you build a whole system to address their problems, you should try to figure out if you can address just one thing that they face on a day-to-day basis. Or see if you yourself can carry out some action that is actually useful to their operation. That’ll build confidence and give insight into the issues that they actually need, rather than what they say they want, or what you project onto them as something that they need, or that you build into a system because it’s something that you are interested in, but has nothing to do with their problem. These are all things that can invisibly contort projects into things that serve a different end goal than providing actually helpful functionality.

5 Likes
14

I’ve been in this situation too, both as a sole developer and in very small teams - so I can feel your pain. By the sounds of things I’d say you’re doing very well considering the situation.

There’s already a lot of very good advice in this thread so I’ll just touch on a couple of things that worked well for me.

  1. Have a prioritized list of work (a backlog or whatever) with highest priority items at the top. You may have to maintain this list but the client is responsible for setting the priority. Actually, only the top of the list is important (and these items should be well specified). But this can help to improve relations and remove stress because when the client asks for another new feature or to change something that has already been changed a few times already, you can just say “sure no problem let’s add it to the list”. And then at some point they get to prioritize it. Also you may have a lot of influence and be able to affect the ordering decisions so that things are in a more logical order - basically helping the client to help themselves - but they have the last word.

  2. There should be one person (product owner) with overall responsibility on the client side - or at least one person that is overall responsible for communicating that vision to you. In the end you can’t accept different direction from different people at the same time. That doesn’t mean that you can’t work with other people on the client side but someone must have the final say so that you get clear direction. And it is this person that decides the priority of the list in point one.

  3. This has already been mentioned, but I think it’s very important to have regular scheduled meetings/calls to discuss the work in the list and to show that progress that is being made or clarify any doubts about specifications etc. These could be separate meetings or all done at the same time - it depends on what works best for everyone involved.

  4. Try to bring the client on this journey with you - explain about the list/backlog, product owner and scheduled calls and explain to them how this is going to help you all work better together - try to bear in mind that the people on the client side are probably doing their best too and all this is a bit alien to them :grimacing:

3 Likes
15

Yes! It sounds very enticing to just slap on a few more weeks, before actually shipping a first version, to have some more time to add new features. But in reality risk just grows and grows. I’m very aware of the dangers of postponing go-live.

Thanks for noticing :slight_smile:

We’ll be transitioning into a second phase soon. I’ve already arranged to be working on-site some days of the week, which will be a very interesting experiment. I’ll try to tighten some feedback loops and take ownership of keeping more order in our backlog. Meanwhile we’ll invite them to take on the responsibility of prioritizing the most pressing features for the next development cycle.

Thanks everyone taking the time to add to this discussion :pray:

2 Likes