When I was first told of the opportunity to join the project in St. Thomas, I was genuinely excited. Besides being able to do the work that I’m trained to do, and being around people whose company I generally enjoy, the stage for all of this was set on an island in the Caribbean. The potential for greatness was high, and despite the challenges ahead, I felt empowered to overcome them. Not long after I started on the project though, I longed for the day that I would return home for good. Still, despite the downfalls and difficulties, I was able to claim victory, even if it didn’t matter to anyone else.

To say that the project had its difficulties is an understatement. I was walking into a hostile, competitive and uncertain situation. Multiple different vendors and the client all had their hands in the analysis, design and delivery of the project, and there were indications that our company’s presence was unwelcome and seen as a threat. Throw in the fact that the multiple, concurrent workstreams that were going on were loosely defined, unstructured and inconsistent, and the potential for failure increased. There were even horror stories where new people who were slated to join the project were put through an interview process almost as soon as they stepped off the plane! Fortunately for me, that never happened, which took away some stress of the project. Still, there were enough uncertainties that left me wondering if things would work out for me.

Instead of being situated near the rest of the UX consultants and client team members, I was whisked away to a different room, to work directly with the client on a completely separate workstream. Only after a couple of days was I introduced to the rest of the team, of whom its members were generally surprised and/or unreceptive. It would take another few weeks to be co-located with the rest of the team, as more work was thrown at me.

The work I was doing had no real structure to it. I was asked to design flows and screens for applications that had no real requirements. This is not to say that there were no requirements; rather, I relied on use cases and other artifacts to inform my work, only to be told later that the resources I was using were not approved, invalid, outdated, and/or changed. The requirements gathering process in itself was broken, because requirements were defined as things were designed and developed, instead of defining them prior. The reverse and circular nature of this process caused more work to be thrown away than used. And because multiple people were working on artifacts at the same time, there was no time or thought put into making these things wholly consistent.

The project timeline was also up for grabs. Deadline dates were set and passed, without any real consequence, which made handling scope creep much more difficult. The deadline dates were meant to set expectations when the team would move out of design into development, but because of the ambitious nature of the project, the unwillingness of stakeholders to agree and commit to scope, and the general disregard some stakeholders had toward the deadlines, it was impossible to provide the team with definite dates to move from phase to phase. The project plan had become a running joke, which is never good.

Later on in the project, the direction had changed dramatically, to the point where most of the project team was sent home, and instead using a smaller team to focus on certain aspects of the project. This was meant to bring in the design phase more, and utilize key resources on the important pieces with which to go live. Unfortunately, because of the main focus on technology and implementation regardless of requirements, most of the business and UX consultants were let go, save for me and one other colleague. The hapless souls that remained inherited all of the unfinished work, which meant mostly everything on the business side.

With so many difficulties and obstacles in the project, it’s hard to imagine how one can make the best out of the situation. Admittedly, there were times when I didn’t think it was possible to do so, which only contributed to my stress level and fueled my desire to leave. Still, I found those things that kept me going, no matter how insignificant they were in the grand scheme of things.

Joining a project filled with many threatened people from other companies on it can either be seen as a blessing or a curse, depending on the type of person one is. For me, I chose the former as my approach, letting my words and actions play more into their insecurities. Sure, it’s not the nicest approach, and not one I’d recommend if one wanted to be friends with these people later, but the only way I could cope with the project and its faulty routines was to make them work the way I wanted them to work. Speaking generally, I introduced best practices in writing and maintaining code, different approaches and paradigms into application design, and a small, iterative process that sped up requirements writing and information design. The result: a set of requirements and wireframes that were deemed to be more complete than any other application, a trust among certain UX consultants who valued my opinions, and the slow demise of others who couldn’t keep up or adapt.

When I wasn’t doing UX work, I found myself presenting it to the client. This gave me the opportunity to use much of my training as a facilitator and presenter. I wasn’t going to allow myself to be sucked into meetings with no agenda and no desired outcome, which was the client’s modus operandi. Instead, I felt the need to facilitate the meetings: honing discussions to topics only I deemed important for the people in the room, tabling other discussions that were meant for different audiences, and respecting the amount of time all of us had to be in a conference room together. After all, with the number of consultants that were in the room, it’s very easy for the cost of a meeting to go up exponentially.

I would be lying if I said that these things made all the difference on the project as a whole. All of these small successes contributed to won battles, but ultimately the war was lost. If anything, what these things did was make a difference on the project for me. As horrible as this may sound, I learned that the success of a project may never have anything to do with one’s individual success. However, it’s important to respect this decoupling, because it shows that one’s individual success can be achieved despite the success (or failure) of the project. For my part, my satisfaction on projects is dependent on a sense of accomplishment, and having a finished, usable artifact to which users can react. The fact that I can’t have the latter doesn’t have to affect the former, though it would be nice to have both. Having only achieved the former, albeit in low, infrequent doses, I was able to keep going. If one can extract value for oneself — any value, no matter how small it is — then there is success.