Could it be?

[Former Member]

It has been quite some time since I wrote a blog. Not that I didn’t have the urge to share something with the world, rather that this was possible within the 140 characters limit of twitter. In this period a lot has changed as well, although the more things change they stay the same…

Climbing the classic ladder of the project hierarchy (I leave it open whether this even has a justifiable frame of reference or not), one thing became clear to me: the meetings I attended rarely covered the real goal of the project. Although this is a very blunt statement, a certain amount of truth can be found in your meetings as well if you look from a certain distance. Yet you and the project team are not necessarily doing something wrong, at least not if you take the adopted methodology as a reference. This doesn’t mean I don’t believe in true project methodologies like proposed by PMI in PMBoK or Prince2 or even ITIL (yes a maintenance project is a project), it only means that I’m convinced that they waste a lot of paper to tackling their own weakness: not having an answer to the question ‘What does your customer really want?’

Truth should be told, once you have answered this question, the PMBoK will help you executing the project. You will be able to guide even large teams along a very long path to completion. With a solid project charter you can create a Project Management Plan, WBS schemas, project schedules with critical path analysis, resource planning, risk analysis,… Regular meetings should as suggested be used to tackle these risks, protect the scope, the planning and adapt to those changes. And yet somewhere amongst those meetings and resources the spirit of the game gets lost in translation. The ‘get requirements’ activity is only one of 42, but for those who are building the finished product and those who will have to work with it, the most important one. The amount of time invested into this phase is spent on workshops, key-user interviews, getting to know the stakeholders, etc. But as with most things, the output of this activity is important, not how it was built, this is out of scope (pun intended). Ending up with a project that is very predictable in cost and timing is no exception, but was all this time wasted in meetings well spent? The discussion whether an item is a change request, because ‘out of scope’ or a true incident or bug is often a very personal and touchy subject that undermines efficient meetings and possibly the project atmosphere. It might be me, but this seems to be avoidable.

With AGILE, although not a real project methodology in my eyes, we are closer to the ideal situation. At least you are honest. You are developing towards an optimal customer satisfaction, but at the same time, you know you’ll need several iterations and reinvent yourself and your solution before this can possibly be the case. Clearly this methodology takes away the overhead and formal aspect of your project team and involves everybody to the maximum. On the other hand, the kindred spirits are bound to lose time in fantasizing about all possibilities and fancy solutions or accepting too many change requests late in the development cycle. The cost and timing results are often nowhere near the budget and planning, instead the customer settles for ‘good enough’ technology within those constraints.

The getting to know the real requirements of the AGILE methodology bit by bit, is so efficient that doing it even before you start your development and while working only on paper (or post-its) opens real opportunities, it can fill the void other methodologies leave and lead to a perfect symbiosis. Involving many people within your target group as well as within your project team during interviews and brainstorming about a solution and perfecting it together creates a common sense of responsibility and manages the expectations in all directions. As you align your team, you will need to tear down some walls within your organization, as business, functional and technical people need to sit together in order to make it work. Could it be that this was exactly why we got into what we do in the first place? To get to know the users we are doing it for and truly helping them? Could design thinking really be the solution to our frustrations as technical consultants and the answer to the question 'What do you really want?' Could it be?