Pasi Kovanen

By Pasi Kovanen

Software with Passion.

People working in big corporations are used to very specific project delivery models. Often the model consists of tens of Powerpoint slides filled with milestones, gates, steering groups and whatnot. It's not uncommon that the model is only understood by a handful of people.

Smaller companies, on the other hand, often have no formally defined model at all. This was the situation at Vincit also a few years ago.

However as the company grew, working in ad hoc mode started to cause troubles:

  • sometimes same mistakes were repeated
  • there was no easy way to spread new practices through the whole company
  • customer's experience varied based on the team they worked with
  • it was difficult to grow new project leads

We established a small working group to create a minimum viable model. First the group came up with some main requirements for Vincit's project model:

  • it must support all kinds of projects (most of Vincit's business is customized agile software development, but we also do various types of consulting)
  • it must not limit freedom of choice and agility - the model should tell what to do, not how to do it
  • it must fit on one A4 sheet
  • it must be compatible with ISO 9001:2008 certification
  • it must not prevent continuous improvement

After several iterations Vincit Project Flow was created, and here you can find the latest version of it (click the image to view it in full size):


Project Flow is essentially a check list. It does not guarantee that a project will be successful, but it helps to prevent stupid errors and unify customer experience.

You'll find several mentions of BIT in the flow. BIT is Vincit's internal tool used for project's time tracking, budget management and developer allocation.

Small changes are made to the project flow several times per year and they are announced to employees using email.

Project Flow has pretty much fulfilled our wishes - however we had to relax a bit on the A4 requirement, but the flow is readable if you have good eyes. Fortunately our printers also support A3!

Did you enjoy this article?

Give us a clap!


  • Jussi Kirkkopelto

    Nice, thanks. Good that it doesn’t dictate agile development itself much – so it may remain true agile.

    I hope your e-mail list is secured from outsiders.

  • Pasi Kovanen

    Thanks for the comment. If waterfall is the best choice for the project, definitely our model must support it as well!

  • Nice work, guys! Simple, yet complete that will definitely help the organization. A question: Have any experiences to share how well this model ensures business agility? To me it seems there are symptoms of Water-Scrum-Fall in your Project Flow; meaning it allows the development team to be agile but there is a (possibly big) upfront investment decision on a pre-defined outcome within a predefined schedule leaving business outside the agile world. Just my interpretation; maybe there is something behind the Project Flow that is not visible to me… Perhaps one could squeeze the whole lifecycle depicted in the Project Flow within each (product) milestone? So after every couple of months (milestone, release) evaluation would take place: did we achieve the business goal? Did we make the impact we were after? If so, let’s invest more & continue with the chosen path. If not, let’s try some other approach or let’s stop spending more money.

    However, I must admit that I haven’t seen so far any real life agile – or should I say lean – delivery model that would use a product funding model instead of a project funding and that would take business into learning/feedback loop. Only in books so far 😉

    “Projects end. Successful software doesn’t.” – Allan Kelly

  • Hello Ville

    Thanks for an excellent comment and sorry for the late reply!

    I think that fate of the project is typically sealed in the sales phase. Fix scope & schedule & budget and you’re doomed. We never do this, as our thinking follows the agile triangle:
    (in English:

    Even though our model doesn’t dictate how the work is done, in practice all our project teams meet the customer once every week or two week. The meeting has elements of sprint review & planning. Evaluation you mentioned takes place in these meetings. Often projects have also steering group practice which is more business oriented meeting about once a month.

    Customers have realtime access to the backlog during the project lifetime and are of course allowed (and encouraged!) to modify it when there is a need.

    Does this clarify the model? Does it make any sense? I’d love to continue the dialogue.

    • Ville Marjusaari Pasi Kovanen

      Thanks, Pasi, for the reply! You are absolutely right, the sales phase is crucial. Thinking through agile triangle is something quite different what I’ve used to see & hear – in a positive way. I’ve seen it so often that the discussion goes to “iron triangle” and agility is nothing but a buzz word and for development teams only. Great! Do you have any concrete examples, even small ones, how your “thinking through the agile triangle” appears in the sales phase?

      Having the customer present in review & planning is a good baseline, I’d say. Backlog is, however, often a shopping list and the link between a single backlog item and a business objective might not be clear. Therefore I feel that there should be another layer of followup & steering that sets the next business objectives, or impacts you’re trying to achieve, and builds the bridge, assumption, between the impact and backlog items. Perhaps your steering group meetings provide those objectives & connections?

  • Pasi Kovanen

    Please download “Ohjelmistokehityksen ostajan pikaopas” (our guide in Finnish for buying software development) from It is an important part of our sales, and discusses quite a lot the agile triangle. In a sales meeting it’s also one of the first things we present, as this thinking is so fundamental in Vincit. It’s also contradictory to what we are taught e.g. in universities, so I assume customers are curious to find out why we say that they are using wrong project metrics.

    You’re correct, it’s possible that the review meetings can focus quite a lot on the functionality – and they should. Also, business leadership of the customer is not required to attend those meetings. This is exactly the reason why we have introduced steering group practices: to get a helicopter view of the project and concentrate more on business aspects and strategy.

Leave a Reply

Your email address will not be published. Required fields are marked *