Wednesday, February 26, 2014

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

Wednesday, February 12, 2014

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

Monday, January 27, 2014

Fare in the Air

As a kid, I loved travelling in airplanes.  The process of getting to the airport, boarding a flight, meeting the airline crew was exciting to the mind of an 8-9 year old.  Once seated, I would look forward to what I viewed as the highlight of the journey – the Airline Meal!  I would anxiously look back where the meals would be stored and wait with bated breath to see what would be served.  I loved being given a choice of two, sometimes three (wow!)  options at serving time.  My mind would register in slow motion the entire process of being asked my choice followed by the steward picking out the tray, then adding a dinner roll (sometimes) and then setting it on my tray.  By far, this used to the best part of my trip!  Needless to say, I would devour the meal and sit back satisfied till the next surprise would show up.  And I happily ate every one of them!

With experience and exposure to food, I got more discerning of food choices and tastes. I have come to realize that airline food cannot compare with restaurant food. Of course, there is a huge difference between a freshly cooked meal and a pre-cooked one. However, I have to admit the excitement still lingers.  My favorite food items are the cheeses and the butters. Put in between a roll, the resulting sandwich is the best comfort food when you are so far away from home, in the middle of nowhere. I would like to see a hotter tea and coffee beverage, though. These for some reason are almost always lukewarm.  The foodie in me also wishes for green tea options or a cappuccino offering. 

In all fairness, some airlines do make an effort to make sure their meals across the board are above average.  Food is a major expense for the airlines and they are realizing that investing in it a little to satisfy the long haul passengers helps the bottom line.  Here’s a fun factoid on why airline meals taste the way they do.  Altitude apparently changes the taste of these pre-prepared meals, which are previously cooked and chilled.  

All in all, the kid in me still eagerly awaits the food cart for the “main entrĂ©e” that will accompany me while I catch up on a movie I’ve been meaning to watch (selections of which are incredible on some airlines, but that’s a discussion for another time!)

Do you have a favorite airline meal or a carrier whose meals are just delizioso?  What are your thoughts on the bento-style tray that we get served?

Charmi Ramchandani

Account Manager

Thursday, January 16, 2014

You have worked here HOW long???

No, I don’t usually get asked quite in that tone of voice, but it seems in the current climate that it becomes more difficult to find people who have been with the same organisation for extended periods the way it was in the “old” days. This is strongly evident in the repeated services we offer for training new analysts.

Let’s face it, new blood is good. If you spend too long doing the same thing, it can get stale after a while. New faces bring new perspectives, new approaches and often new attitudes. It may sometimes take a while for these to come to the forefront, but they most likely will.

However, this must also be balanced against a wealth of experience held in the hands of the old timers. They know the people, the processes and the technology with which they have been dealing for years. They know who to go to when needed, what workarounds exist, and generally how to make things happen.

But my favourite training line usually brings horror to attendees’ faces: “What if you are hit by a bus tomorrow?” No, I am not being pessimistic, but accidents do happen. What happens to that wealth of information in the unlikely event of an accident? Your Business Processes, manuals and documentation most likely cover the strict guidelines, but seldom are the workarounds, the personal relationships, the tricks of the trade laid down for future generations.

Whether it is a formal training session, consulting interviews, or just a general client visit, getting feedback from everyone is always interesting. Sometimes it requires pointed questioning, at other times hypothetical scenarios, but in most cases, people want to share information. They may simply not have had the correct platform or reason for doing so. Sharing it with us reinforces our partnership, and in many cases we have acted as a type of repository for information which has enabled business continuity in unforeseen circumstances.

And acting as that repository also allows us insights which give us more ammunition when thinking about problem solving approaches. I like to think that over the years I have picked up a thing or two. Sometimes that little revelation from a year or two ago may trigger an approach which would otherwise have been missed. And if I hadn’t been there for that discussion a couple of years ago, I wouldn’t have heard it mentioned. Not documented, but mentioned, possibly over a coffee break or the dinner table.

This first day of January heralded the start of my 16th year with Revenue Technology Services. I deal with new clients regularly, but am still in close contact with some of the same clients that I was on the day I first started. Their businesses have changed and evolved, as has ours, yet in the spirit of partnership, we continue to grow together.

Even 16 years later, I still look forward to meeting with the clients, as each visit brings something new. The interaction never becomes stale and even repetitive activities, such as training new analysts, still brings new information to light.

When chatting to Raja Kasilingam recently, one of the things I had to highlight was that although I have been here forever (and I am not our longest serving team member), each day still brings new challenges, seldom a dull moment, and I still enjoy coming to work.


So the answer to the opening question: “Far too long, but not long enough”

Tuesday, December 24, 2013

Real-Time Revenue Management

One of the things that we have been hearing a lot about lately is the ability for real-time optimization of a single departure or a group of departures.  This has many benefits for those departures that tend to get a significant number of bookings in the last few hours prior to departure – especially in the cargo and passenger rail industries.  The objectives of real-time revenue management are two-fold:
n  React with minimal latency to dynamically changing market conditions.
n  Especially useful when significant booking activity/schedule changes occur during the day and carriers cannot afford to wait for nightly file updates and processing
RTS is currently reviewing many options on how best to approach real-time revenue management.  One approach is:
n  The inventory control system senses change in booking activity and sends alerts to the revenue management application based on user defined thresholds, i.e., cancellations, bookings greater than projected demand, etc.
n  The revenue management application gets the latest booking, cancellation, schedule change data in real time from the central reservations system (inventory refresh) and automatically optimizes these departures and sends updated allocation levels back to the reservation system.
n  Two-way real time interface between the central reservation system and the revenue management application would need to be developed to facilitate dynamic data exchange between the systems.
The pros to implementing real-time revenue management consist of:
n  Boosts the bottom line by making optimal decisions based on real time information minimizing lost revenue opportunities.
n  Improves analyst productivity by reducing rework on a number of stale or invalid controls.
n  Automatically identifies departures that need to be re-optimized and eliminates the need for the analyst to continuously monitor changes in market conditions.
The downside of implementing the above is:
n  May not be worth the investment if market behavior is relatively stable and predictable
n  If thresholds are not defined accurately, it may lead to uncontrollable number of alerts being sent from the Central Reservation System to the revenue management application impacting performance.
We believe that the ultimate approach would be a combination of nightly processing and the ability for the system to send alerts so that the analyst can actively review those departures that are falling outside of the user defined threshold parameters.
RTS values your input and thoughts and the enhancements to our products.  Leave a comment and let us know your thoughts.
From all of us at RTS we want to wish you a very Merry Christmas and a Joyous New Year. 
Robert L. Harris, Jr.
Senior Solutions Consultant

Wednesday, December 11, 2013

Hyperloop

It is the latest buzzword in the travel and transportation industry where passengers can travel between 2 major cities which are less than 1000 miles apart within 30 minutes, at a speed close to 800 mph. Another one of Elon Musk’s newest inventions and an extremely powerful, practical one which has become a jaw dropper in the Travel and Transportation industry.  Existing conventional modes of transportation of people consists of four unique types: rail, road, water, and air. These modes of transport tend to be either relatively slow (i.e., road and water), expensive (i.e., air), or a combination of relatively slow and expensive (i.e., rail). Hyperloop is a new mode of transport that seeks to change this paradigm by being both fast and inexpensive for people and goods. A mode of transport that is a cross between the concorde, a rail gun and an air hockey table.

When it will become a reality is yet to be seen, but for now the authors are calling this an “Open Source Project”. It has an open design concept just like Linux did decades ago and is now a reality. The first version of this design involves passenger and the second will be passenger and vehicle.

In lines with the Hyperloop, a more comprehensive project is the Aqua=Terra T.W.I.N.S. (Trans-Web Infrastructure Network System) projects (aquaterraplanetaryholdings.us and invention.net/aquaterra) that not only provide for an advanced transportation system, it also includes a complete self-sustaining format that links, via sub-surface Tubes, land (Terra) and sea (Aqua) Stations to form an international / single-standard web system.

 We at RTS, love to research and analyze any new trends that will help companies in this space integrate profit optimization and revenue management into their existing business processes and systems. Since we work with both Passenger and Cargo, it is very exciting to learn about the specs that the Hyperloop has presented to enable them to make use of our wide product range.

The Hyperloop concept is the first of its kind to ever to be created and there is no doubt that above a very sophisticated software system/s that handle the data, visuals, reservation, financial, reporting, there is an important layer of software which is a profit enhancement system that will that make sure there is benefit and optimized use of the seats/cargo space within the Hyperloop.

Some questions that will linger on for now on our minds - What is the capacity? If it cannot meet the demand will the prices go up? Is there is a long wait time to use the Hyperloop pods, will people find themselves having to take an alternate mode of transport?


The move toward higher speed, better service, cheaper travel, and something less environmentally polluting, is going to happen — it's the wave of the future.

Deeshi Gandhi
Technical Manager

Thursday, November 21, 2013

Ah - Blog Time Again!

Just what is a Blog? According to Wikipedia, it is “a discussion or informational site published on the World Wide Web and consisting of discrete entries ("posts") typically displayed in reverse chronological order”. It goes a little deeper in a subsequent paragraph to indicate “Many blogs provide commentary on a particular subject; others function as more personal online diaries; others function more as online brand advertising of a particular individual or company.” Since this is the Revenue Technology Services blog, this obviously fits quite nicely into the description of online brand advertising. However, the pertinent section here to my mind would be “commentary on a particular subject”.

Internally, we are all tasked on a rota system to come up with these blogs. After a few rounds, you would think that inspiration for new topics or ideas would be lacking. Yet it is surprising how this inspiration can typically come from nowhere. Personal blogs tend to range from the informative to the wild rant, but corporate blogs tend to focus more on the business itself. So as not to be too repetitive, when the baton is passed to me, I cast my eye back over previous blogs on our site. When doing so today, what I noticed was this: we have articles covering various aspects of our product line and functionality; we have articles discussing trends in technology; most importantly, we have a number of articles regarding our people.

In the many years I have been with RTS, our buzzline, catchphrase if you will, has always been “People, Processes, Technology”, and that is exactly the information we have been communicating. And communicating is the key. Through the entire implementation cycle, and into our ongoing client support activity, we stress communication.
  •         During initial project planning, communication is key to ensuring both we and the client are on the same page regarding expectations as to which people are assigned, what processes will be adjusted, and what technology will be implemented or affected.

  •        During implementation, communications become even more crucial. Among project team members, it keeps all appraised of the status, progress and potential hurdles. As part of change management, good, continuous communication from the outset keeps all stakeholders aligned regarding how the business will adjust to the new functionality.

  •          During education sessions we stress the importance of communications, and that the RM team cannot effectively operate in a vacuum. Methods of information sharing are identified, and suggestions made for keeping all aware of what is going on within RM.

  •          After go-live, we pride ourselves on maintaining communications with clients, allowing us to garner feedback, understand their business and changes for which we may be able to offer advice.

  •          Our annual user summits allow for further, interactive communication between ourselves and clients, but additionally between clients, and prove very beneficial.

Even the rare negative feedback is still positive communication, as it helps us improve our People, Processes or Technology.


And there we close the loop. A blog is communication in a short(ish) chunk. It allows us to communicate with you, the audience, on a regular basis, giving an insight into who we are and how we think. So, how about “communicating” with us, to let us have your thoughts and feedback on this or any of our other blogs, and make this a truly 360 degree experience.

Jason Codd
VP Services