Project Blog: Lessons Learned

As I come to the end of one project and have another significant one ramping up, it is always good practice to review the lessons learned and check what could be applied to the upcoming project.

The ‘lessons learned’ title seems to suggest that it is about things that might have gone wrong and need preventing in the future.  But this is only half of the picture as it should also include positive aspects of a project that worked well, and make sure these are repeated.

It may seem some of these things will be obvious, but I find it very useful to remind myself of good practice, making sure these are put into practice and become a habit.  A simple example would be the best practice of the weekly project meeting and providing a structured agenda to facilitate a productive meeting and avoid wasting project member’s valuable time. This should be followed by minutes and well defined action items with agreed dates. Sounds like the basics, but I bet we’ve all been in formal meetings were it does not happen.

With a new project on the horizon, review the lessons learned log from these past previous projects or discuss with the project team for pitfalls, concerns, or positive experiences. Or just simply review the known best practices, which is of course applicable to all areas of business and not unique to Project Management.

Mistakes are inevitable in any project, it’s not the end of the world, and it’s not about assigning blame, rather having open and honest discussion and communication. The important thing is to learn from any mistakes, identify solutions and promote the positive aspects of any lessons learned to make sure mistakes aren’t repeated, but equally ensure the good things are used again.

Typically lessons are captured in the review at the end of the project and have mid- or longer term gain on future projects. In reality it should be seen as a continuous process as ‘lessons’ can happen at any time in the project and it is worth considering getting the team together, individually or collectively, and asking what could we be doing better right now or what is working particularly well?

• ·         Review learned lessons from past project at start of new project to see what can be applied.
• ·         Discuss items/concerns with a new customer for their typical issues/concerns or best practice.  
• ·         Setting up a project lessons learnt log at the start of the project. Make sure everything is captured and not forgotten. Act immediately where appropriate.
• ·         Checkpoint once a month in the weekly meetings. This can help identify and correct any concerns/issues on an active project and reap benefits immediately.
• ·         Review at new project phases when new team members may be introduced.

So why not use the knowledge gathered and experience gained in past projects, from whatever your previous or current role or perspective, and prevent the same mistakes being made from previous projects, or apply the best practices.

Lessons learned should:

• ·         Focus on quality not quantity. Typically the top 10 should suffice (for both positive and negative).
• ·         Be specific and realistic.
• ·         Have agreed recommendations.
• ·         Do NOT criticise individuals (or be used for settling scores!).

I read blogs or other articles similar to this and often think ‘yeah, I know that!’ and they serve as good reminders for commonsense tasks or practice,  but do I always put these things into practice and make them a habit?  Sometimes it seems there are too many current tasks that need attention and the focus is on getting those completed. But spending a little time now to reflect and adjust may reap significant rewards immediately or later in the next project.

So, my next task is to review the lessons learned and best practice from similar past projects as I start the initial project planning on the next one...

Patrick Allen

Senior Consultant and Project Manager

The Case for Use Cases

In any software business or industry, a Business Analyst should be able to write flawless use cases so that the resulting document is crystal clear to a layman, in this case, a software developer who has a little or maybe no domain knowledge.

At RTS, we are lucky to have a development team offshore who is knowledgeable of not just the software platform that our product is created on but also the domain knowledge.  This setting makes it easier to transfer the use cases to the team and receive back a resulting product with close to 100% accuracy without too many iterations.  In the case where there is lesser domain knowledge, it would have been as good as writing the ‘Hello World’ program within a couple of minutes but not knowing what ‘Hello’ and ‘World’ means! That being said, it is also impossible for one person to gain both the technical and functional knowledge of a business requirement and hence the necessity for both the teams to work closely with each other and having a good method of understanding each other’s language that is on the use case document. At RTS, we proudly boast  that the turnaround time for an enhancement or a new feature is short because of this set-up.

My approach to writing a use case is that I use the bottom up approach, since knowing the end result of what is required helps drive the details. Once the end result is known, then working backwards in order to get all the parameters, rules, pre and post conditions, flow and exceptions are just adding details to achieve the end result.  Another effective approach is to involve the business owner/s so as to make sure that it is on the right track. Agile methodology works here, but from the second draft onwards, because the first draft needs to be done in its entirety to give the business owner a full overview of where it is headed before submitting it to the development team.

One last important factor that helps me create a use case is to put myself in the shoes of a layman  so as to get a feel of how easy/difficult it is to understand the intent of the use case on hand. If it is easy enough that the terms, language, diagrams are all flowing, then it is a success and if it is not easily understood, then  maybe tweak it to achieve that.

How do you create your use cases and deliver them to your teams? What are the 2 best approaches that you have come across? 

Deeshi Gandhi

Technical Manager