Close
Written by

Michał Stankiewicz

My first project at Objectivity – Planning

According to Alfred Hitchcock, a film should start with an earthquake, and then the tension is to keep on rising incessantly. It sounds like a perfect description of my first project at Objectivity, which I am going to tell you about with great pleasure.

In a few posts to come, you will have an opportunity to find out about the biggest traps and mistakes our team has come across, as well as their consequences and the ways of dealing with them. I will also tell you what I learnt about my new workplace during the project.

Beginning

The day we met the client, which was to prepare for another common project, started in high spirits. A quick check-in at the airport, coffee time, which gave us one more chance to look into the material prepared and to discuss the action plan. Within the next two days, we were supposed to understand the needs and expectations of the client the best we could. It was also essential for us to place them in the context of business processes and long-term strategy, so as to be able to maximize the value given. Last but not least, we found it important to spot any potential mines, which could turn our idyllic trip into a 12-round heavyweight fight. All in all, all signs showed that we were well on the way to kick off with the next project.

Initial shocks

The first scratches in our perfect plan started to appear shortly after the beginning of the meeting. The number of issues raised, and the related requirements exceeded our expectations. The analyst and architect bent over backwards to build a consistent image. Unfortunately, the answers to most of the questions gave rise to yet other seemingly not related issues. The number of notes and mock-ups kept rising, however we did not have a sense of progress or a feeling of getting closer to the goal. Instead of bringing the actual answers, the questions became a source of an increasing sense of the unknown. Fortunately, thanks to the upcoming deadline, the project sketch started to emerge together with some ideas for further steps.

Have I used the word project as singular? Oh, sorry…I’ve meant several projects, four to be more specific. Each of them could easily keep a team busy for a few months. One may think this is great news. A big number of projects is a dream of every company delivering IT solutions. I must admit that initially that was also the way we thought. We started planning the next sessions, during which we would specify the requirements, analyze the risk, and come up with an action plan that could be carried out in a peaceful and methodological way.

What stopped our daydreaming and wishful thinking was the client’s question ‘’When will you be able to start and why is it taking you so long?’’ …

‘’0’’ hour

‘’0’’ hour started straight after coming back from the Client and lasted for about two weeks. At that time, we managed to prepare and obtain the approval of four backlogs, carry out four estimations, and create a schedule as well as the estimate of four projects. One of them was to become the first project at Objectivity. As luck would have it, in the case of that project, we also managed to make several mistakes, which were to teach us a lesson and remind us that haste makes waste.

The first, and at the same time, the biggest mistake was to devote insufficient amount of time to analyze the requirements of one of the stakeholders. The requirements for the product delivered had been defined by two teams on the client’s side.

  1. Business – the main recipient and user. This is the organization that involved the Project Sponsor and Product Owner.
  2. IT Department – responsible for technical development, ecosystem maintenance and verification of the delivered code in terms of compliance with the accepted norms.

The requirements of the second team had not been properly taken care of.

The second mistake was to start the estimation with a long list of the unknown and the related assumptions. For instance, one of them concerned the trouble-free use of the external supplier’s control. A closer look helped us make sure that all the scenarios were supported. Unfortunately, due to the time pressure, the second plan was missing, which could help us check if all components put together work seamlessly.

We will raise the topic of the other mistakes and their consequences later on, but what we are able to say now is that the project was underestimated. We did realize that delivering the solution within the fixed period of time and within the appointed budget, would pose a real challenge.

And then, an earthquake started. A day before the beginning of the project, the client changed the day of solution delivery by two weeks earlier in relations to the initial plan, leaving the budget at the same level.

Aftershocks – dear Team, please get familiar with your project

Before getting down to work, the Project Manager’s task (i.e. my job in this case) was to prepare and organize a kick-off meeting. Its aim was to provide the team with as much project-related information as possible. We discuss a business case, the main business and technical assumptions, potential risks and problems. It is during such meetings that we take a final decision which frameworks are going to be used, be it SCRUM, Kanban or something else. We also establish specific steps of software delivery. As you can probably guess, the key to success is that all team members are extremely involved and participate in the decision-making process whenever it’s possible or necessary.

That’s it when it comes to the theory. My first kick-off of a 3-month project, with 13 people involved, took 1.5 hour. That’s not much, especially that the very preparation took me much more time. The biggest part of the meeting was of information nature only. As a consequence, I missed an opportunity to take advantage of the team members’ knowledge and experience, which in turn could result in finding ways of avoiding or minimizing potential risks and problems.

When I go back to the moment of taking the decision regarding the length of the meeting, I suppose that I acted under the spur of the moment, which seemed to accompany us from the first day of preparations. At that moment, the most important issue for me was to tick off another step in the process, which is a kick-off. Consequently, I didn’t focus on the bigger picture, where achieving the meeting goal was the key task as far as team work comfort and completing the plan is concerned.

I guess we can call a day at this point. The next stages of the project as well as the problems and solutions, will be discussed in the next posts, the first one to appear in a week.

Share this post on

Tags

Leave a Reply

Required fields are marked *

Read next

IT systems design in the eyes of a PM

Have you ever had an opportunity to manage a project with business and technical requirements being documented before the beginning of the project? And while presenting the first (or another) version of the project, it turned out that the Client had seen it differently? Or maybe you have taken part in a project having no specific requirements and starting with […]

Read more