Well, well, I did not intend to induce any mental somersaults or brain acrobatics with ‘start at the end’. However, this I felt most aptly captured my learnings of the summer of 1998. The title of my post, must intrigue you. Standing a logical journey on its head with the end at the start in order to reach the beginning?

We are entering a brand new 2018. And what better time than now to talk about goals for the New Year? Making resolutions, setting fresh new goals and working towards set goals…. isn’t that what the New Year starts with? Much later in life I learned from a Robin Sharma course on self-mastery, ‘Vague thinking leads to vague production and that clarity breeds mastery’. This is about experiential learning on getting clarity on work goals, larger project goals and achieving the desired outcomes.

Summer of 1998

My story dates nearly two decades back.

It was towards the end of spring in England. If you have spent spring and summers in the UK, you would agree it is one of the best times of the year there.

Great weather, beautiful sunshine with light showers and flowers blooming everywhere. In and around the town I lived, with picturesque parks and the countryside, white sheep were lazily dotting the rolling greens. Spring was still in the air and so was it in the step of each person on the team.

The Project Begins…

I had started my new assignment as a systems analyst in a major business transformation program. The client was the financial division of a world class company. The stated intent of the program was to integrate discrete accounting systems into a single back office system.

We were a fantastic team.

We had started the project on a great note. It was as if everything was just right with our work and the environment around us; I so vividly remember the breezy, lovely, late spring, early summer feeling.

The team was in place. Resources were assigned. There was appropriate integration of the team with vendors. We had regular meetings planned to review progress and the project was tracked by an efficient and diligent Project Manager.

With the objective of integration and replacing some of the smaller individual systems with a new back-office system, we laid out a new database. Interfaces were defined so data could be pulled from discrete old systems including the mainframe systems. User profiles were specified. The build of reports from the back office was initiated with dummy data ahead of the integration being completed.

A Bump in the Road

And then came the milestone review. This review became the bump in an otherwise smooth rolling project! Nay, it was more of a huge speed breaker. We had suddenly encountered it, without seeing any sign of it ahead of reaching that point. It had brought our smooth running project to a screeching halt, just short of a massive accident and its aftermath.

I can never forget that meeting with Ronald Taylor (name changed)! Ron as he was known, was our key stakeholder, the department head. Five of us on our project team of 20 were meeting with Ron to report the project progress and to review the reports’ design.

We were quite looking forward to the good word from our ‘client’ for having progressed so well. We kind of knew, we’d walk out of the meeting with a pat on the back for a job done well, thus far. In our minds it was a foregone conclusion.

But that was not to be.

We had completed project updates and we were half way through the meeting. All seemed well. As we started reviewing the reports with Ron it was evident his discomposure was increasing with every report that was being pulled up on our presentation screen. Finally the discomfort that was building up, exploded.

Ronald expressed his displeasure.

The Feedback

  • The team had not understood certain crucial requirements
  • We had missed some strategic objectives
  • The need for certain reports was imperative to achieve the goals of the department and the company as a whole
  • However crucial report parameters were missed
  • The specific data views to achieve the reporting outcomes were not available in the new design
  • These were management reports fulfilling the needs of decision makers to have certain data points at their finger-tips
  • The reports were to enable efficient monitoring of their respective streams of work and equip executives to enhance operational performance with agility

The reports were to specifically provide certain metrics that were in fact the stakeholders’ KPIs. They were crucial to keep a close eye on, in order to potentially advance the business as a whole.

Back to the Drawing Board

So, we took it on our chins. We returned to the proverbial drawing board, to revisit the blue print of our project requirements.

Several huddles, critical introspection and stakeholder interviews later, led us to a stronger place and a sound foundation for the project success.

What we as a project team had missed, was critical. And, what was the outcome?

  1. Our pre-occupation with the integration objectives over shadowed our end customer goals and objectives. This jolt to the project brought them into clear relief and we saw and understood them crystal clear.
  2. In fact, we had to start with answering the fundamental question: Who is the customer, the real stakeholder?
  3. We revisited the goals of the project and rose above the parochial view of integration of systems to the more strategic objectives of easy data access and monitoring of key performance indices?
  4. With a better understanding of our customer and their objectives we could appreciate requirements of the ‘on-demand’ real time reporting versus the batch reports for the project.
  5. We were able to clearly define the measurable success criteria and hence the acceptance gates
  6. Integration of systems into the new back office system now became the means to an end; i.e. the means to meet the strategic goals and objectives, needs and requirements.
  7. We now took into account usability and user experience, and performance criteria for building the on-demand reports and output for each stakeholder.

Well, those were the years when software engineering as a discipline was still evolving.

The team took a serious note of all the flaws, strove to cover the gaps, fortify project requirements and define the needs with clarity.

Back on Track

With a new plan, we got back on track. Albeit some delays and the sanction of a commensurate increase in the project budget, we eventually delivered the system to our clients’ satisfaction.

As a systems analyst on the project, I was a relative minion, but I had got valuable first-hand experience; how requirements are defined by the goals and objectives the project is meant to achieve.

The Lesson… start at the end

The profundity of the lesson struck me as never before or after.

I moved on to take on tougher assignments, more complex multi-site projects and led large transformation programs in due course. The étude was not lost.

3 crucial parameters remained the cornerstones of successful deliveries hence.

  • Identifying the real customer (user),
  • Understanding and validating their strategic goals and objectives and
  • Regular stakeholder engagement through-out the project

At ReignSearch, we have made this lesson the foundation of understanding and defining project requirements and achieving successful outcomes.

Whether it is the need for a new website or leveraging social media for targeted outreach, whether it is inbound marketing or the mobile applications for marketing, our approach and process makes for unfaltering accomplishments.

It does not however mean that at ReignSearch we do not face challenges; our delivery framework allows us to start on a sound footing, course correct sooner than later and achieve high client satisfaction.

Not only for a greater rate of success with our projects but in our endeavour to over deliver, we have developed and in fact enforce a basic, yet effective framework for requirements definition.

The moral of the story and the lesson from that English summer remain etched on my mind: Get clarity of the objective and the end goal you want to achieve (start at the end) so you make the right beginning and eventually finish on a successful note, not to forget, with intermediate validation.