Innovation>Design>Action

The most agile project I worked on was not called “agile”.

It was my best project experience ever.

I got assigned as a business analyst to a project. Within nine months, with a small development team of five, we’ve designed, developed, tested, and launched a new application that won one of the highest quality awards in that Industry. Not only we’ve re-engineered a key business process, but we’ve also implemented a new way to calculate a critical metric that was treated as immutable and untouchable for many years.

One of the business stakeholders called our approach to the solution a “paradigm shift in our thinking”. Another skeptic, reluctant to support the project early on, ended up its fervent supporter, calling it “the one project for the record books”.

And most importantly, our team has never been more energized, inspired, and cohesive than when we all worked on that new system.

How did it happen?

For me, that project experience became the benchmark for all other projects, development teams, and solution designs. I don’t know if I will ever get to feel the same exhilaration, so this article is my way of highlighting what made that experience of building a solution to a business problem so successful.

1. Non-trivial business problem

It is easier to succeed when a project is small, the problem is relatively trivial, or the focus is on incremental improvements of a regular and predictable process.

When the scope is contained and well-defined, the path forward is clear, and the work is more likely to be executed without major challenges.

However, a trivial business problem does not require us to stretch our thinking, imagination and creativity and test them to their limits.

The problem we were asked to resolve confounded business stakeholders for years. The opinions of those who understood the problem ranged from “exasperating” to “hopeless”. Many factors played a role:

·?????Legacy systems with rigid designs and lack of flexibility to support regional business rules.

·?????Reporting programs built dozens of years ago by people who have long retired leaving no documentation behind.

·?????The culture of reverence for long tenure and old ways of doing things.

·?????Reliance on local “Excel wizards” to execute many manual steps in the process using their tricks and secret procedures that could not be replicated or automated.

·?????The complexity of business rules and their flexible interpretations due to lack of enforcement structure.

·?????Regional competitiveness for performance indicators tied to remuneration.

·?????Previous unsuccessful attempts that created a perception of a “doomed project”.

Our team had to deal with all these factors. Any one of them could have been the straw to break the camel’s back. In this article, I will share what helped us overcome these challenges.

Looking back now, I will feel proud about achieving what we have achieved.

This pride comes from knowing that it was a difficult problem to solve, and many naysayers expected us to fail.

2. Strong business champion

Changes fail for many reasons. Even well-designed and executed changes can fail spectacularly given sufficient resistance.

This resistance to change and the power of the old guard that says “we’ve always done it this way” is often so strong that even obviously beneficial innovations get rejected.

In our case, we couldn’t even start the project because of the resistance. A key Stakeholder ?“product owner” declared their non-support of the initiative and bailed initially but got convinced later after solidifying the thought behind the this innovative move.

Under these circumstances, we needed a business stakeholder who would believe in the project and support it all the way.

We needed a champion.

We found one by presenting our innovative idea to the panel of senior executives. One of them stepped up, knowing full well that they were staking their reputation on the support of the innovative idea and challenging the old guard.

We were lucky — this business champion played a huge role in the success.

Without the business champion’s backing, believing in our idea and motivating the rest of the business group, we could not have done it.

3. Discovery phase that produced a viable idea

Non-trivial problems require innovation and a change in thinking. When you try to solve a problem that seems unsolvable, it often means that you must think differently, look from new angles and discard old constraints.

A typical project lasted 9 months — to be completed by the year-end.

And our tiny team had two summer months for discovery and planning, and this is when the magic happened.

The discovery was very informal. Lucky for us again, the subject matter experts we needed were dedicated, extremely intelligent and open to innovation. I spent many hours with one business expert who happened to have planned their vacation at another time.

He was really excited about changing the current clunky and cumbersome state of the affairs. He explained, waved his hands, and used colorful analogies to explain the problem, which I knew nothing about before then.

He has been in the field before — and could answer even the most detailed questions. We’ve done experiments and root cause analysis, compared the actual business events to the data that was captured about these events in the system. We scoured the data. We brainstormed. We played with many ideas. We hit pay dirt.

?The project has yet not officially started.

My business expert was giving me a lot of time because he was excited about solving a difficult problem.

It was a challenge that tickled his mind and gave him the satisfaction of innovating. He was motivated, and his eyes shined, and we remained great friends, bonded by this creative experience.

And we had an idea.

4. Idea validated through a proof of concept

Our brainstorming resulted in an idea that needed proofing. Can it really be done? Do we have the technology? Do we have anyone who would be able to do it? Would this give us what we want?

Again, we were lucky. Our solutions architect and one of the smartest developers?in our team and they both loved the challenge.

Our idea had to be tested on a new technology: we had to connect to the enterprise infrastructure that we’ve had no experience with. It included major design and performance challenges. It needed to be solved early on — if we couldn’t handle the volume and velocity of data through a new data pipeline, everything else would fall flat.

This is what famous Google thinking days must feel like.

With no administrative overhead and the motivation of a difficult problem, we were free to think the bravest thoughts, and then test out the craziest ideas.

Eventually, our innovation team of two developers produced a promising prototype. This idea could work!

5. Autonomous, co-located and cohesive team

Once we had our innovative idea and the project champion, we needed a development team. The organizational structure helped: we already had a business analyst, a solutions architect, and developers in the same team, and didn’t have to go through much. We were an established cohesive unit and knew each other well.

After completing the proof-of-concept, the team was ready for performing.

How were we autonomous? There was no leadership parachuted down that we needed to explain the ropes to. No contract project manager was hired last moment to “manage them and make sure they stay on track”. There was no outsider who thought their job was to ask “How long will it take you to do that?” and “What is your percentage of completion?”

The project was managed by those deeply involved with the project.

We’ve quickly grown into a truly self-organizing and cohesive team. Our ?project manager was busy with other things but supportive — by allowing us to create a sensible project schedule and then be left alone. My business analysis duties blended with project coordination.

We made most decisions together and it worked.

A few other factors helped us to become a high-performing team:

·?????Range of expertise: we’ve had business analysis and development expertise within the team which made the team self-reliant.

·?????Co-location: both in a physical and organizational sense.

Self-containment drastically reduced the overhead, fluff and miscommunications, let us focus on designing the product, and created a sense of accountability.

6. Clear leadership structure

The team needed someone to be in charge of tracking decisions and actions. It fell naturally to the business analyst.

It became a feat to produce anything meaningful while coordinating endless governance meetings with all the nominal stakeholders who had no time to give except to consume endless PowerPoint slides and ensure that nothing happens without their blessing.

On the opposite end of the spectrum, we’ve had a single business champion ready to work hard on the project and secured all the business resources.

There was no need to dance — our project governance was very simple.

There was no one on the project who was unclear what their role was. And it was the responsibility of the project lead and the business champion to ensure this was the case throughout the project.

With simplicity, comes clarity of accountability.

7. Business team commitment

Business champion’s leadership provided the backing needed to have a strong and involved group of business stakeholders. This is where we veered far away from the scrum principle of having a single product owner making product decisions.

To create a product and a process that works for the whole enterprise, with all its regional differences, we’ve had representation from each business unit — from the beginning to end, with equal say.

Our business team was truly brilliant, for a few reasons:

A) Corporate project assignment was a promotion steppingstone, not a burden.

A company culture to assign the best and most promising business leaders to projects (not the ones who had nothing to do or whom you wanted out of the way). That gave them an opportunity to apply their expertise in a novel way, learn new skills, succeed and shine. That also allowed the company to test and pick out the best of the best for the next promotion or challenging role. And these helped projects succeed.

B) Mutual respect.

Everyone on the team had respect for the business champion’s knowledge and authority. Debates were frequent and hearty, but most decisions were reached via consensus. The champion had a decisive vote, but this right was never exercised without rationale. There was an atmosphere of sincere respect among the team members, a result of a wise team member selection.

C) A culture of dedication.

The team was pulled from the busiest operations groups where only those who worked hard survived. There were no slackers. A couple of freeloaders were politely asked to delegate.

Anyone could call anyone’s bluff, and if you didn’t do your part, it was painfully obvious, so it almost never happened.

D) An incentive to succeed.

The product we were developing would have a clear benefit for the business stakeholders on our team. Everyone was interested in ensuring their regional rules and needs were taken into account, and to achieve that, they had to show up and participate. Snooze it and lose it.

8. Immersion into business process

Discovery and business analysis started with immersion. The business analyst — sometimes accompanied by the architect. We wanted to experience all the realities, pains and hiccups of the current process. And we go what we wanted.

We’ve seen so many manual steps, tricks and cheat sheets. We’ve explored and got lost in dozens of Excel spreadsheets. We’ve heard many stories despite that gone through existing processes

That gave us an appreciation for complexity that couldn’t have come across from the cut-and-dry standard operating procedures. We witnessed the tricks that were never documented but helped complete time-sensitive tasks and avoid major disruptions. This allowed us to discover many undocumented exceptions that we would need to account for if we wanted to implement successful process automation. And that allowed us to discover the challenges that the new solution would need to overcome.

From that experience, I learned that?immersion is necessary any time we work with legacy business processes that were in place for a significant time.

Processes can and will deviate from process documentation to accommodate exceptions, new rules, missed requirements, and to avoid prescribed steps that no longer make sense.

9. Data-based scenario analysis

Immersion can help discover many exceptions and gaps that we cannot glean from interviews and artifact analysis. However, to have a complete picture we also need?data. The most obscure issues, and those that can cause most problems, per Murphy’s law, will not surface on the day that we plan our immersion visits. They will happen according to rules we are unaware of, and we will experience them randomly, even if they have an objective reason.

If we don’t know the root cause of these exceptions, then we may encounter them by accident — which often will be in production and after the solution was developed. To be proactive, we must?analyse the data?to detect anomalies and exceptions — or to validate that all scenarios have been discovered and captured.

Using data to validate business rules and requirements will depend on the nature of the problem. On this project, as we worked on a set of business rules that would be the core of the new solution, we validated each rule through data. Every time we found a production case that didn’t fit our ruleset, we would investigate.

The investigation would result in one of the following outcomes:

·?????Data anomaly or bad data.?This required an explanation of what happened and why. Often it led to an investigation and changes to operating practices or training materials.

·?????A legitimate business scenario. We then researched to understand it, captured and modified our business rule-set to accommodate it.

·?????A legacy scenario that should be decommissioned.?These we captured, described, and then decommissioned in a planned manner.

Data analysis as part of business analysis enables the discovery of gaps and exceptions early and allows to incorporate a more complete set of business rules into the solution design.

10. Shared understanding of business requirements by all stakeholders

Nobody wants to read a 100-page document. Our business team, however dedicated, was no exception. They wanted to fully understand the requirements but had a prejudice against long documents. Having seen some of them, I could understand why.

As a business analyst, I needed to find a realistic approach. This is what we did:

A) Regular requirements validation during weekly meetings.

Every time we made progress, we reviewed, captured, and validated the requirements and rules using production data. This was done by using shared screens and viewing the scenarios, the data, and the outcomes together. Synchronous review and validation in small increments were doable, easy to understand, and became a natural conclusion of the weekly meeting cycle.

When the analysis was completed, we still had a big review, but it was built on all previous just-in-time validation. The overall approach was more efficient and business-stakeholder-friendly.

B) Validated requirements captured in real-time and always accessible for reference.

Once the team agreed, I captured each requirement in the main document. This part had to be built on trust — a business analyst only captures what was validated, and the team trusts the BA not to sneak anything in or change the meaning.

This approach requires that the business analyst is accountable for the integrity of the overall requirements set.

C) New analysis findings continuously compared to already captured requirements.

Every time we had ?a working discussion, anyone from the team could find the right place or the most relevant requirement. We would check whether it still held considering the latest findings, and if not, update the requirements or flag it for the next team review.

Most of the time, it fell to the BA as a custodian of business requirements to flag new discrepancies. We shouldn’t rely on stakeholders to remember all the minute details and flag discrepancies — this is where business analysis techniques come in. Business analysts can use diagrams, matrices, state charts, decision trees and many other tools to validate new information against what was previously collected. Part of their job is to check all the time that the house of cards is still standing.

This constant calibration and course correction during requirements analysis is only possible if we are diligent about?structuring our requirement as we go.

D) Use a variety of structured techniques to validate the big picture regularly.

I’ve used diagrams at every meeting — highlighting, coloring, moving boxes around, planting big question marks next to problematic areas. I’ve included snips of the diagrams into meeting notes and emails to get them reviewed and clarified. We used them to clarify misunderstandings and misinterpretations, especially at the start when dealing with ambiguous local terminology.

My stakeholders have gotten used to the visuals and they became our shared method of quickly getting into analysis and digging deep to get to the root cause of the problem at hand. They helped us communicate efficiently and generated many fun moments and insider jokes.

Do not be afraid to use models with business stakeholders. You are working with smart people — you just need to establish a common language and use it consistently.

11. Innovative solution architecture

No success would be possible even with the best intentions if we didn’t have an innovative idea for the solution. The proof-of-concept gave us reasonable confidence to proceed, but to build a solution to scale we needed a robust and implementable solution architecture.

That was the big constraint. For years, many very smart people built procedures and algorithms to work around the imperfect system. There were macros, spreadsheets, additional scripts, aggregations, and sub aggregations to the point when nobody could prove the lineage of any particular data point anymore. It was like looking into a deep dark well where you were not allowed to shine a flashlight.

Instead of using aggregated data derived through outdated rules, the new solution aggregated and enriched data using the rules the business designed and controlled.

The solution required an innovative approach to data acquisition, filtering, and wrangling. We were disconnecting from the legacy source that was everybody’s Holy Grail for half a century and building a new direct pipe from the feeder stream into our own pond.

We’ve re-engineered everything — data sourcing, business rules engine, aggregation hierarchies, master data management, and all the workflows. It was an architecture challenge, and it gave us so much satisfaction to be a part of the design. And most importantly, it?solved the right problem.

12. Solid data foundation

One of the problems with innovative solutions is their naive idealism. New technology, new tools, and gimmicks attract attention and look shiny. It is more exciting to design a new workflow, embed a Chatbot built with some mock data to test the ideas, or create a splashy UI to wow the stakeholders with a new user journey.

It is more boring and tedious to worry about where the data would come from. Data pipelines and sources are usually messy, incomplete, and foil innovative ideas by lacking crucial data points. While young and motivated coders want to build new apps, machine learning models and responsive flows, they sometimes expect someone else to do the grunt work of acquiring necessary data. They may design assuming a perfectly logical data model — only to discover the real data model is cumbersome, patched up and supported by a hodgepodge of weird data structures. Without the right data foundation, the solution will remain an empty shell.

Our project engineered a new data pipeline from the central hub. We’ve build a data model, built a data-mart fit for the purpose, and the rest of the solution design then fell into its place.

Workflows, business rules, user interfaces, exception processing and analytics will only work if the data foundation is reliable and sufficient.

13. Agile mindset

Doing something new involves trial and error. In an organization with a waterfall mindset, we practiced trial and error — informally and organically:

·?????Tested, tweaked and added business rules based on data analysis.

·?????Modified data acquisition algorithms several times to optimize the rule performance as the rules changed.

·?????Discovered new scenarios that could only be exposed once peculiar data anomalies were detected and investigated.

·?????Engineered user journeys incrementally, allowing for gradual acceptance of the new business process where the roles had to change significantly.

·?????Built and improved a new interface to support unit testing that has evolved it into a popular product feature.

We tweaked requirements and design when it made sense — without procedural fuss.

Some organizations like to go for “rah-rah”– announce that they will become agile by the end of the year, hire expensive coaches, plan retreats and certify everyone in something agile. This by no means improves chances of project success. Agility is a mindset and cannot be replaced with a set of rituals. Building agile teams in rigid matrix environments is like trying to grow lettuce on the forest floor. The native vegetation tends to stifle the intruders and suppress them into limp existence or extinction.

Our project was not officially agile. We had a waterfall project schedule. We didn’t have a single product owner. We didn’t use the A-word. But we’ve had the mindset. Within each phase we did what made the most sense and what the team agreed would give us the best results:

·?????Development team co-location and frequent informal meetups.

·?????Constant requirements grooming and validation.

·?????Direct immediate access to business SMEs and their deep involvement in analysis.

·?????Reliance on data to validate and resolve requirements conflicts.

·?????Early prototyping.

·?????Continuous testing and incremental design.

·?????Trust to make requirements tweaks and design changes without bureaucracy.

·?????Open communication and room for respectful disagreement.

·?????Clearly visible and rigorous tracking of tasks and actions.

·?????Spirit of individual accountability.

?14. Optimal project rhythm

So we didn’t have a “project cadence”. We had working meetings.

We have worked out a project rhythm that facilitated efficient work and maintained it until we were done.

There were no complicated schedules with different levels of committees and subcommittees meeting various days of the week, bi-weekly, thrice-monthly or on alternating Thursdays. There were no separate status meetings, stand-ups, retrospectives, requirements workshops and walk-throughs. There was no need for one level of governance to keep another level of governance informed through a special communication schedule.

There was no time spent on tracking who was invited to which meeting, who needs a “touch base”, who would have to be separately informed, who was accidentally left out and is now pouting, or endless rescheduling.

The core of this rhythm was a weekly two-hour working meeting. Whatever needed to be brainstormed, debated, resolved or debunked, became the agenda for the next weekly meeting. Whatever needed to be investigated, analyzed or collected from other sources became a take-away for the right person or a breakout group.

Outside of the weekly meeting, we were in constant communication and picked up a phone if things needed to be cleared up quickly.

Why did it work?

A) Full commitment to the meeting time.

Everyone committed at the beginning to set these two hours aside for the project. Our busiest team business stakeholders rearranged all their other regular huddles, meetings and committees to be available at the same time every week for the next nine months. We’ve never rescheduled it.

B) Optimal meeting duration.

This was not decided without an argument. The culture of one-hour meetings was prevalent. Two hours sounded preposterous at first. It was a big commitment. We debated having two one-hour meetings instead, but it wouldn’t have been the same. We needed a?thinking meeting, not a status checkpoint. Eventually, the team agreed to a two-hour weekly project meeting — and it became everyone’s favorite time of the week.

C) Weekly cycle for takeaways.

Naturally, not everything could be solved even in a two-hour meeting. Team members frequently had takeaways for research, breakout huddles, data gathering and analysis. The results were required for the next project meeting. With one weekly “quorum time”, everyone had a clear deadline for completing their action items. No time wasted discussing and writing down due dates. No excuses about not having time. Our business team included high-performing individuals that did not get to where they were by being lazy.

Everyone was accountable for finding time to work on a priority project within their weekly cycle.

15. Continuous validation

The agile mindset of the team drove one informal rule.

Anything discussed at the weekly working meeting had to be validated by the next meeting.

Wait any longer — and the discussion and arguments will be forgotten. The team will move on to other challenges. The emails will drop lower in the inbox, the data will become stale, and it will take longer to recall the thinking process.

Enforcing continuous validation is the responsibility of a business analyst. Through the business analysis process, we have to capture enough to explain and justify each requirement or rule and ensure it can be traced back at any time — to the owner, the business policies, and any other drivers.

What to validate? How much? Where is the line between trusting the business stakeholder and doing fact-checking? This is where the business analyst’s experience and knowledge of the organization come in. We’ve used many methods:

·?????Individual review?with the business expert

·?????Data analysis:?does the data support expert opinions?

·?????Logical checks:?does the set of rules still make sense when a new rule is added? Are there any gaps in logic? Any scenarios with undefined outcomes?

·?????Team review:?what will the new requirement change? How does it impact what was agreed earlier? Are there contradictions that need resolving?

·?????Business modelling:?how does the new rule or requirement change the working models? Does the flow change? Does it close any loops or create new dangling points that require resolution?

·?????Review with the development team?members: does the requirement make sense? Is it implementable? Sometimes, a technically inclined person needs to be left in peace to mull over the requirements to figure out what does or does not make sense. This is a valuable trait, but we need to give these people space and time to think. Then, get them to talk and voice their concerns. We have found quite a few challenging or contradictory requirements this way.

·?????Recap key points?at the beginning of the next meeting. The team may have all agreed on a point last week, but there is always a chance that it was done too hasty or that someone’s attention wandered. Seeing the idea with fresh eyes a week later sometimes drew an instinctive “Wait a minute!”

We trusted each other’s instincts and re-validated anything that created a sense of unease, doubt, or vague premonition.

Of course, documentation played a crucial role in not rehashing the same doubts. Sometimes, a compromise was necessary. Once agreed and blessed by the project champion, every compromise was documented as such, to avoid a new cycle of discussion.

16. One central place to share everything

It’s JIRA – The Project Management tool

It’s not the tool — it’s how you use it that matters.

Our project was very structured, predictable, and comprehensive. At the risk of overusing the expression, it was a one-stop shop for everything to do with the project.

17. Predictable & disciplined communication

The pace of the project was relentless. The team was distributed across multiple regions. Some of us have never met.

So the communication rhythm was followed religiously. Communication patterns had to be maintained — this created the habit of the team members to expect and respond to communications. This, in turn, made managing the project much easier.

All our project communication patterns amounted to:

·?????All meeting notes were in one place and always posted within an hour after the meeting.

·?????Each action item had an owner and a due date, and every meeting started with action items. Every team member knew who was doing what and when.

·?????The project plan was color-coded and reviewed at the beginning of each weekly 2-hour meeting. Five minutes were sufficient to bring everyone up to date with the status and obstacles thanks to the continuous communication. There were no boring “project status meetings” recounting milestones and haggling over percentages.

·?????All important deadlines and dates were on the shared calendar.

·?????All between-meetings discussions were on the discussion board, and everyone could participate and see everybody else’s comments.

·?????All emails were sent using a project distribution list and nobody got missed and could then claim that they didn’t know something or get upset about being missed.

·?????A monthly progress report was delivered to the executive sponsor.

·?????Closer to the implementation date, we began communicating to the user groups, training sessions and change management activities. Project team members all became the “ambassadors of change” — each in their own region where they already had a trusted status.

·?????Due to a major change to the existing process, we’ve created a Q&A document that answered every direct question, starting with “Why do we need this” and “What’s wrong with the way we are doing it now”. This had the added bonus of reinforcing the messages among the ambassadors and giving them a tool for providing consistent messaging to the user groups.

There is no magic to good communication. It has to be sensible, adapted to the audience, and consistent.

18. Work integrity

The worst nightmare of a project manager? You create a project plan following all the best practices, establish prerequisites, allow for delays, secure and allocate all the resources allowing for unexpected distraction. You publish, communicate and nurture the plan, and work hard to help team members remove the obstacles and have all the resources they need on time.

And then you start hearing:

I am not quite complete yet.

I had to attend several unexpected meetings.

I wasn’t sure it was needed for today

I’ve had a crazy week.

We were all distracted here because…

Which one is a genuine reason? An excuse? A bad sign?

I was so lucky on this project — I almost never heard excuses. Everybody did their tasks — even Leadership. Everyone was an equal on the project team as far as doing the work was concerned. The culture of accountability made it unthinkable to come up with an excuse.

Everyone was already busy and you didn’t commit to a project if you were not ready to give it the time.

This is truly a nod to the culture of the organization that people showed up for meetings on time and were expected to inform the meeting organizer if they were unable to attend. The business team we’ve worked with was from different verticals, where the culture of being on time was ingrained and omnipresent. It has spoiled me forever and I still cannot ignore lax attendance and casual indifference to completing action items on time.

19. Flexing the milestones instead of the timelines

Our project had an arbitrary timeline, just like any other project in the company. Fiscal year-end was the common denominator and the drop-dead date. The initial plan was to roll out one month before the year

end, as the last month was always overloaded with training and implementation activities — to the point of being unmanageable.

The initial timelines were based on an arbitrary formula 1+2+3+2+1:

·?????1 month for initiation

·?????2 months for analysis

·?????3 months for design and development

·?????2 months for testing

·?????1 month for the roll-out

Needless to say, formulas don’t work well for innovations. It didn’t work for our project either. Business analysis, in particular, stretched well into 3 months even with a fully dedicated business analyst, and a lot of discovery work completed before the project officially started.

It’s also difficult to estimate the development effort for the solution that wasn’t even conceptualized. Nobody knew how many scenarios and exceptions we would find once we got access to the raw data — the data that we never had before.

However, there was still a drop-dead date. Some version of the solution had to be ready by year-end. So we didn’t obsess about things we had very little control over — we focused on what we could influence: the timing of the milestones, and parallel sequencing.

First, the project needed more time for analysis. Officially, the development was supposed to start only after the requirements were approved. Unofficially, the development went through a few iterations by the time we got the requirements into good shape.

Officially, the testing phase required an official kick-off with various approval. Unofficially, we were testing and experimenting midway through analysis, using test results to refine the requirements.

Officially, the solution had to launch by a certain date as a big bang. Unofficially, the implementation stretched into a soft launch, allowing a slower transition from the manual process and giving everyone time to get accustomed to a major mindset shift that the new solution required.

At the end of the day, nobody will care what the methodology was. What matters is the success and adoption of the solution.

20. Camaraderie and personal relationships

This turned out to be a long article, and it’s time to wrap it up. But I can’t omit another crucial factor that made that project so memorable.

The intensity of that project, the constant challenge created an amazing bond among the team members.

The camaraderie we’ve nurtured over time, complete the nicknames and the private jokes, provided a safe environment to experiment, make mistakes, and get over them.

The trust and the common goal provides both the motivation and the satisfaction in the results.

It was exactly what makes humans enjoy going to work every day. I am grateful to have had this experience.

We accomplished so much with just phone, email, work ethics and common sense. This is a big shout out to our project team — you did it!

Stay Tuned..........