Reflections on project management

The discussion #

The saying goes:

If you put 10 economists in a room, you’ll get 11 opinions.

So it seems with project management teams, every team member has their thoughts on how to manage projects. Opinions are plentiful, even amongst team members who share similar roles; although to a lesser extent than those across different roles. Every so often an event will occur or something will be said which once again sparks conversations on how projects should be managed. Much time is then spent discussing everyone's opinions. Often some minimal change will be made, at least temporarily. But nothing really changes. Everyone still thinks the project isn't being run well. People give up and surrender to the reality dysfunction. We do what we can but are secretly bitter, thinking how out of whack things are but accept the current state as being inevitable, as we drift closer and closer to the process becoming a "Bullshit job."

I'm on a team which just recently had another round of these conversations. I participated in the discussion by asking questions but kept my opinions to myself. I've succumbed to being jaded with the perspective that I'll mostly have to jump through the hoops others desire. The best hope I have is to try to get through the process as quickly as possible so I can go about the work. This frustrates others on the team because I'm not leading. I willingly contribute but do not step up to volunteer to be the JIRA driver, organizer or retrospective radiator reader, etc.

In Christopher Voss' book Never Split the Difference, which I haven't read, I believe he argues it's better for one party to give way when there are differences because by compromising neither party gets what they want and so are unhappy. But if one let's the other have their way then that person still feels good because they are supporing the other. Is that a solution to the project management dilema? One person gets their way and the rest follow? Maybe it would work. Maybe at times.

Even if that was an option I wonder if I would take them up on the offer, to volunteer and try implementing my ideal project management vision for the realities of my team. But I find myself hesitant to do so because the probability of my process not being any better is likely. Why take that risk then and face this reality only to lose hope that there is a better way? It's easier to quietly judge from the sideline. But that is not helpful and by doing so I forfeit the right to voice an opinion. It is better to risk, learn, and grow. Here then are my thoughts for the environment my team operates within.

The environment #

We do not have product owners. We do not have anyone to demo to nor perform user acceptance testing. The team receives high level requirements and we are then asked to implement it. We have the ability to ask questions of a business party, but they have their normal job role to perform so interaction is minimal. This limits the possibilities on how the project can be managed.

Management wants to forecast how long something will take and our progress toward completion. The business user cares about a tool which improves the services they provide. My team wants to know what to build and to build it well.

What cannot change #

The process begins with the business communicating their needs. Mangement determines how their request fits in with the bigger picture of the organization. Negotiations are made between the business and management on what will be delivered and its priority. When the time comes management informs my team of the project we will be working on and what it entails. This portion of the project management process will not change, it is the way the organization functions. Perhaps some day someone in a high level managment position will lead an intiative to structure projects otherwise. But for now this is they way projects operate.

The proposal #

The job of my team is to begin breaking down the project into pieces and determine the order of the work. We then start story pointing some of the initial pieces. Implementtation begins once we have initial unknowns discovered, questions answered, spikes completed, etc.

We select the first small chunk of work. The goal should be 5 to 15 work days, but there isn't a set timebox. It takes however long it takes. Once that work is complete we meet. We then reflect. Original story points and number of days taken are recorded. We review the backlog, add more items, estimate more items. We then determine the next valuable thing and work on that to completion. Reflect, Record. Refine. Repeat.

Outcome #

Using this system mangement can to some extent forecast based on story points given and effort taken for each chunk of work. The chunks of work completed should still mostly deliver business value, so the business can see the application as it progresses, if they have capacity, and feedback can be recevied, even if it's just a few minutes of sharing.

Can management achieve the accurate and precise timeline they truly desire? No. Will the business get the ideal application for their needs? No. Will the my team know what they are building which measures up to the quality they desire? No. But we all seem a bit closer to these goals and the process is much more efficient. Additionally this all seems feasible to implement within the currenty structure of the organization.

Reflection #

I started out by bringing up the idea of not splitting the difference, that maybe it's best to let one person decticate how the project is managed. It is not lost on me that my solution has everyone splitting the difference regarding the outcome of the project. If we truly were not to split the difference what would that look like? My team gets to build the perfect project but never deliver it? Mangement dedicates the timeline but ends up with a buggy product and a burnt out team? The business gets a dedicated dev team catering to their every needs but at great expense? Perhaps what's needed most is acceptance. That the world is messy and we prevail by coming together.