...8 Project delivery lessons to learn from
1
A long, long time ago in a land far, far away…. a project delivery team was busily spending their days delivering projects. They were tasked with delivering change projects and often these included software delivery. This team consisted of people with a variety of skillsets, personalities and experiences. Some of them were project managers, some were analysis and some were developers. Others were software testers and others were business experts and non-project people.
Although they were all different and had different views on how to approach things, they were often required to work together on very tight deadlines. These projects were delivered with varying degrees of success. One thing that this team did well, was to learn from their mistakes. They adopted a suggestion to record all of their lessons learnt, in order to not repeat their mistakes and they solemnly committed to do things better in future.
This record of their lessons learnt, was written down, framed and mounted on the walls of their place of work…
It read as follows2 :
Lesson 1:
Don’t use a traditional (or waterfall) approach when most of your requirements are unknown, uncertain or unclear.
If you do this and force business to sign-off on something that they know will change, you are setting yourself up for failure. Your timelines will keep on moving out. This will not be good, since it will cost money…
Solution: Understand what the problems and requirements are, by following an incremental approach. Kathleen Hass 3argues that “iteration is the best defence against complexity”. Following an incremental approach will give you early & quick feedback and learning. Using this feedback, you can adjust course & constantly understand better what you need to build. A by-product of a more agile approach (besides the learnings from it), is that you pull business closer into the solution by communicating more frequently and by confirming correct of incorrect assumptions.
Lesson 2:
Make quick decisions.
Procrastination or lack of accountability paralyzes teams and leads to lack of movement and productivity.
Solution: Make decisions! Maybe even adopt a more autocratic management style (shock…horror!) But make the decision, even if it is wrong. The quicker decisions are made, the better. Clarity creates purpose and indecisiveness paralyses. In the SCRUM methodology, decisions are made daily and any obstacles or impediments) are resolved on a daily basis by a business-mandated person (Product owner). This way the team never loses precious time by waiting for business to make a decision.
Lesson 3:
Have a single, mandated decision maker.
The only thing worse than not having decisions made, is probably not knowing who to get to make those decisions.
Solution: The business or client needs to appoint a single person who can make decisions on their behalf. This is especially important in instances where solutions are created across the whole enterprise. Various different interests across different “silo’s” typically cause lots of uncertainly and indecisiveness and if a single “go-to person” is appointed for the project team to go to, they do not have to be bogged down with the politics and sensitivities around decisions – they simply take their instructions form one person and they move ahead.
Lesson 4:
Stick to decisions and decided principles.
If project teams become aware that decisions or principles are often ignored, they will also ignore them.
Solution: The team have to stick to decisions made, otherwise decisions mean nothing. If the team does not have the assurance that decisions will not stand, they will not through all their weight into it, since they cannot be sure that what they build, might not be throw-away work. This does not mean that decisions cannot be changed, if they were found to be flawed, but once a decision is made, follow it, until it is either implemented or changed.
Lesson 5:
Don’t major on the minor things. Don’t let the plan be everything.
Focusing on the wrong things, is a complete waste of time and effort.
Solution: Identify what is important, prioritise those things, assign the right people to those tasks and leave them to do those tasks first. Many a time projects tend to spend hours and hours on updating project plans, for purposes of presenting these to steerco’s or management teams, instead of having a lighter, high-level view and then exploring only what is lagging or problematic. The emphasis should be on planning, not on the physical plan. (“Responding to change over following a plan” 4). There is nothing inherently wrong with having detailed project plans and presentations available, but if that takes up so much time, that the actual priorities start to suffer because of it, it becomes a problem. Then one should ask if the tail is not wagging the dog…
Lesson 6:
Allocate tasks to the right people
Often times incorrect people are asked to perform tasks for which they are not the best candidates to perform those tasks. This leads to a whole host of negative results, from losing time to skill-up the person, to redoing something that was done incorrectly or improperly the first time around…
Solution: Get the right people doing the right tasks. Do not merely assign tasks to those who are available, willing or those with good attitudes! Rather take some time to find the right (best suited) people, with the correct experience, skills or knowledge to do the task on hand. This is guaranteed to save the project a lot of time and effort.
Lesson 7:
Manage expectations
By not managing expectations all around, emotions flare up, confusion reigns and no proper progress gets made.
Solution: Keep track of (Yes, write it down!) what gets agreed on & decided (requirements), what the progress is in the delivery of these (development) and then clearly and frequently communicate the status of these with all relevant stakeholders. Misalignment in terms of experience is guaranteed to lead to unhappiness and stress all round.
Lesson 8:
Start with WHY and focus on value first!
If one focuses too much on time and cost, instead of on value, you are bound to miss the boat completely.
Solution: Clearly understand at the onset of your project why the project is needed and what problem you are trying to solve. Then clearly identify what would constitute ‘value’. List these deliverables clearly and at all times work towards achieving those identified deliverables. Time and cost will obviously be a factor in achieving your value - goal – but it should not become the goal in itself.
What are your greatest project lessons learnt?
Please share below in the comments section.
Author: Danie Van Den Berg, CBAP
 |
Danie van den Berg is a consulting business analyst from Johannesburg, South-Africa. Over the past 16 years he has worked in a variety of industries. His specialities include Requirements gathering & elicitation (ERP, Web & Android), Business Process Re-engineering, Workflow Automation and process optimisation. He enjoys mentoring BA professionals, teaching business analysis topics and prepping BAs for CBAP exams. Danie is passionate about the role a Business Analyst plays within organisations and believes it is central to changing and improving the world we work and live in |
[1] https://static.pexels.com/photos/461775/pexels-photo-461775.jpeg
[2] Okay… – so the introduction portion of the story is fictitious (obviously!) – done so to protect the innocent…
[3] https://www.batimes.com/kathleen-hass/21st-century-ba-you-are-the-decider.html
[4] Thank you Agile Manifesto http://agilemanifesto.org/