I’ve had a busy weekend, I launched Nexus which I’ll use to manage my LMS project, and I also installed Moodle LMS which I’m internally branding “Sophic“. During this exercise and many times before it on previous projects, my attention was drawn to the relationship between Architect, Engineer and Project Manager.
As a private project, I have the position of wearing all three hats but even in doing so, I experience the struggle of competing interests, priorities and the tension to provide a solution that would keep all three satisfied. For me, this is just internal turmoil, but in the workplace this requires an exercise of communication and trust, especially when a project may rely on individuals who may have very different skill-sets.
Why is it then, that important projects are often left to build on a foundation where rapport building, efficient communication and expectation management are not actively promoted? I might term this as “Team Infrastructure” because basically, that’s what it is.
One reason TI is often neglected might have to do with the difference between western and eastern cultures in how they do business, in a low vs high context cultural perspective, where the latter might better lend itself to laying down a better foundation prior to starting on a project.
However, a more compelling reason might be the simple assumption that the team members, as both adults and professionals, should know how to get along and work with each other. Ignoring that this may not actually be true for the circumstance, there are two main problems I immediately see:
- Efficient communication is so large and important it effectively renders itself invisible by way of becoming too familiar. It’s like furniture that you’ve had for so long, you forget it’s even there; it just blends in.
- Most people are, first and foremost, emotionally wired creatures and conflict is a by-product of social interaction, and so by not actively promoting communication and rapport building, it is easy for people to lose sight of objectivity and suck in all the negativity.
With this in mind, the importance of bringing Team Infrastructure to the foreground is not to be underestimated. Building in and reinforcing TI should be part of the project, it is a task that needs to be started and maintained throughout the entire project and have explicit attention drawn to it. One wouldn’t let a project blocking issue solidify if they thought it would happen, so one therefore shouldn’t leave the success of a project on the whims that the team will simply work.
As such, take the effort to plan regular meetings and standards for communication, try to work some fun into the project to build team rapport, and maintain expectations, of both the project and the team members. Committing a little bit of time focusing on the basics of working as a team, should go a long way in improving a project’s success.
For reference, the top two project based self-arguments I had this weekend were:
1. The type of Project Management Software to use:
- The Architect wanted to go for Collabtive, a very shiny tracker that isn’t appropriate for this project, as it doesn’t support guesting and lacks the proper format.
- The Engineer wanted to go with Mantis BT, something that is fast, nearly indestructible software I’ve previously used, easily customisable, etc, however it’s fairly intimidating for guests to use and has that “What am I looking at?” feeling.
- The Project Manager wanted to go for an all-in-one package like eyeOS, which literally is all-in-one but total overkill. It’s like bringing a tank to break up a fistfight.
Trying to communicate these thoughts and justify them to myself was a task in itself, as I face multiple temptations, and it is only by focusing on the purpose and outcomes did I finally reach a conclusion. I ended up choosing Traq as middle-ground, as although it’s weaker in each aspect, it rounds out very well and ticks all the boxes.
2. Thinking about single-login integration. I’m using Moodle as my LMS and I’m considering OrangeHRM as my Employee Record and Performance Management Software. I could make a single login system possible through LDAP (Lightweight Directory Access Protocol).
- The Architect didn’t really have much of an opinion outside of login screen CSS.
- The Project Manager really wanted a single sign on across both services (even though there is only one user).
- The Engineer also wanted LDAP, as it means less theoretical calls by confused end users about forgetting their password, and it may be a more data elegant solution moving forward.
Sadly, LDAP isn’t an option due to server constraints. Then again, I’m the only real user on the system.
[/vc_column_text] [/vc_column] [/vc_row]
