This week we covered some Human Resource Management, mainly focused around motivation.

The issue of motivation for me is a very important one, as I’ve found motivation in the first semester of fourth year much more of a struggle than any of the previous years, in all my educational career.
For CS4457, we dealt largely with Motivation in a larger company & team. How do you keep your employees invested in their work?
The two forms of motivation, extrinsic & intrinsic paint an interesting picture for me. I didn’t realise how ultimately ineffective money is as a motivator, likely because money is held up as some end all & be all, which I see a lot as I look for Graduate Positions for next June and beyond.

The idea of ownership, of self-investment and contribution is an interesting one in the area of Software Development, especially in a market so beholden to customer requirements.
In Software Development, Extrinsic satisfaction seems to come more from positive feedback, self-directed work hours, and simply self-satisfaction.
It is, as our lecturer pointed out, why developers participate in Open Source Projects, free of charge, for “the love of the craft”.

We also learned about the Pomodoro Technique, which I’ve attempted to put into practice since then.
It basically involves

• break down all work into 25 minute chunks
• focus only on one task item for 25 minutes (a single Pomodoro)
• restart the Pomodoro Clock if there are any interruptions
• take a small break after each Pomodoro and a longer one after four Pomodoros

I immediately saw the benefit when the lecturer was discussing this and my attempts at implementing it have been helpful, if not 100% successful. The “Age of Media” is a distracting one but ultimately surmountable.

——————————————————————————–

The Team met on Friday the 11th of November for approximately 3 hours, where we put the finishing touches on our individual documents, making them aesthetically similar and then combining them into a single document. This session was particularly productive, with the team all getting on quite well and happy to be finished a week before the deadline, especially as some of us had just received another assignment in a similar module.
We just waited on one person’s self-summary and evaluation over the weekend, but ultimately we were finished!

This week covered we covered more Risk Management and Outsourcing.

The Risk Management we covered was largely focused on different methods of evaluating Risks and how both priority and impact are very important when it comes to evaluating Risks.
An example of this is the improbable data leak of customer’s private data due to the hacking of a database server. This may be improbable, or lower on the probability of risks, but has huge impact that could irreparably damage the product and the company, so it should likely be addressed on some level.

The Use of Out-sourcing & Third-Parties in Project Management was something I was interested in, because Ireland’s largest (and arguably sole significant) impact upon the Global Games Industry has been Havok, who provide Middleware (as a third-party) to thousands of Games around the world.
Another factor in my interest was while not necessarily a third party, my Co-Op was in the Offshore Development site for the American-focused Fidelity Investments.

I’m personally quite supportive of some level of out-sourcing, I believe re-inventing the wheel to be too much of a resource sink especially as software becomes more Service-Orientated and generally Cloud-focused. Out-sourcing allows the developer to focus on fulfilling the business requirements rather than implementing every little sub-feature themselves.

I understand the necessity of good Procurement Management though, as acquiring incorrectly understood or unsuitable software can be costly in both the short term (intial licence) and long term (making extensive changes to fulfil requirements in this & future products).

A notable case of Out-Sourcing gone awry is the controversial video game Too Human. The developers, Silicon Knights licenced the early version of Unreal Engine 3 as their core engine for the product, with expectations of assistance & quick improvements from the Engine Developer, Epic Games. When this did not happen in a timely manner that suited the development schedule of Too Human, Silicon Knights sued Epic Games for breach of contract. The case is still on-going almost 5 years later.

—————————————————————————————————–

For the Team Project, I completed my main contributions to the Proposal, but we did not meet this week.

This week we covered some of Risk Management.

While an interesting topic and one that conceptually makes sense (predicting what will go wrong and what to do when it goes wrong) I understood why it was the least mature knowledge field in any kind of production.
Not only could one call it a misnomer, a fair amount of it is covered in different areas of Project Management e.g. Change Requests (for currently unknown but potentially risky changes likely required at a later date). So there’s a fair amount of material that could be considered Risk Management already covered when doing Project Management that isn’t necessarily classified as Risk Management exclusively.

Some of the risks that I’ve encountered in the workplace amounted to

• Data centres suffering power cuts (so we had a backup in a different state that the web service would automatically switch to).
• Incomplete Data in the Application due to otherwise occupied customers

Knowing how to prioritise risks, like server/data centre fails is key and when to accept certain risks are beyond your control e.g. You can’t force your customers to fill in their data.
Having fallback plans like having an An-Call Team Member is especially important in cases where your technology is being used in timezones outside your own, even if it is just to cover the 1% failures.

After the lecture I attempted to research the Delpi Technique, as I hadn’t heard of it, but save for the Wikpedia article (which largely referenced Books about the Delphi Technique) the majority of the websites were very critical of the Delphi Technique, that it’s largely used an attempt to manipulate others into agreeing with your perspective while making them feel involved.

—————————————————————————————————–

For the Team Project, Gillian, Kieran and I met in CS2-44 and showed each other what we had done, conferred and edited the Documents (using PMBOK), before assigning the remainder of the documents to be finished. Selene participated virtually, via Google Documents.
These 3 hours were very beneficial in developing an understanding of the assumptions we had each made and how far along in the project we were.
We decided that due to more project work due earlier we would not meet again until Week 10, where we would put the documents together and put the finishing touches on the project.

This week we covered Quality Management & some Communication Management.

Personally I find Quality Management an odd area of Project Management, due to it being (I’d have argued) self-evident.
The attempt to stick to ISO or CMMI guidelines is not something I’ve experienced or heard of much, that often it’s more low-level guidelines like

• “We want 85%+ Code Coverage by Unit Tests”
• “We want 97% Uptime per Year”
• “Mobile Browser support is desired, but not mandated”

Quality Controls for Documentation & Requirements was a more interesting topic for me, as I was more ignorant of it.

Making documents in specific formats to ensure proper Change Request procedures are followed, in the interest of everyone involved was interesting to me, and how these Changes had to follow a Quality Set of Guidelines to ensure the Project was not too way-laid by these new requirements/change in focus.

Coincidently this tied to Communication Management.
I enjoyed exploring how many stakeholders there are actually are in a project, that analysis can show their may be regulatory bodies as stakeholders, depending on the product, which I had not considered at all.

Similarly, the I.T. Department, who provide the hardware for e.g. Web Services and therefore need to be involved at an early stage to ensure there are not delays in deploying the project.

I really found the “Media of Communication” Evaluation interesting, because as arguably subjective some of the values were, I was interested to see where a meeting was less effective than a telephone call or an e-mail, because meetings are often held up as the “Be All & End All” which I don’t necessarily agree applies in all cases e.g. Companies whose employees operate completely in the virtual space, not even sharing an office e.g. Frictional Games.

The idea that conflict can be a good thing was an interesting topic too. Of course this is just work item focused conflicted, rather than more personal conflicts. The “Yes-Man” work mentality can be negative and it was satisfying to see this pointed out and agreed upon, as it often stifles innovation.

—————————————————————————————————————————————————-

The Team didn’t meet this week due to deadlines & exams in other modules

This week we covered Leadership Theory.

I found ‘Leadership Theory’ quite interesting because for the past few years I’ve been on Society Committees, so I’ve been in many positions of power (psuedopower at least) and in sitautions where Leadership is vital.
I personally believe Leadership is both a genetic trait & taught skill. An instinctual leader may make poor leadership decisions merely due to a lack of experience, and vice versa, a leader who has had plenty of training doesn’t necessarily have the trait necessary to react with the correct level of leadership when confronted with a situation they weren’t trained for.
Similarly I think one can be a good manager without being a great leader but it certainly helps to be both.

I hadn’t heard of Contingency Theory, nor how it tied to Leadership. Found it interesting, but somewhat obvious that we one style of leadership and organisational structure would not suit every company.

This seemed to be building towards independence in the workplace/having some level of ownership. Which is why I was happy when we covered the fact that as a Project Manager, micromanagement is not only impossible to achieve, it’s a negative management ideal, that working to facilitate your teams to complete their work is the bet thing a Project Manager can do. From personal experience, the PM really is the “Communicator”, who is constantly in communication with one of the involved parties, whether they be higher management, the customer or the team.

In a Software Environment, I really feel that a credible PM has to have a good deal of Development knowledge, if not experience. If they didn’t, I don’t think they’d appreciate the challenge often faced by the team, the complexity of the system and despite how simple a task may be conceptually, when implementing it is not necessarily so.

——————————————————————-
For our Team Project, we did not meet this week, but continued to work on our assigned documents.

The focus for the rest of these reflections shall primarily be the Team Project.

The Team :
Gavin Fitzgerald
Gillian McMahon
Selene Mok
Kieran O’Brien

Having been put into Teams somewhat randomly in a tutorial previously, we began to get more aquainted with each other through tutorial excersises, which amounted to apply a WBS (Work Breakdown Structure) to a bicycle.
First breaking it down into its different parts, then applying some level of ordering. Our ordered version amounted to little more than a numbered list, which paled in comparision to some of the diagrams by other teams, so I consider this an important lesson learned.

Then the details of the assignment were handed out, and our team decided to meet up in CSIS on Tuesday, 4/10, Week 5 of the College Semester. Here we went into a lab, sat at two computers and reviewed the specification for the project. We talked through the different documents, trying to help each other understand what was required and how we could assign different required articles to different people.

But we struggled. We found it rather vague, especially because each of us missed a key detail about the nature of the Project Proposal Required. So I e-mailed our lecturer and we decided to meet up on the following Thursday evening, to properly bite into the project, hopefully with a better understand of what was required.

At the tutorial, on Thursday Afternoon, we questioned the lecturer and he helped us grasp a firmer understanding of the fact that after the Project Charter is completed we’ll be in a better position for assigning work to different people. That evening, Kieran, Selene and I went to an empty lab in CSIS and sat down to hammer out the charter. Gillian couldn’t attend as she had unexpectedly been assigned to work that evening.

We worked from 6 to 8, with Selene and I alternating between who would be at keyboard (with the other 2 members sitting next to & dictating) in a manner somewhat like pair programming. We used common sense & what we had learned in lectures/previous employment for a lot of what we came up with, but when it came to specific finacial figures we searched for likely amounts based on similar situations.

At the end of the night, we volunteered for which document each of us would take to work on (within Reason, due to us CS Students having big FYP deadlines in Week 6 & Week 7) and assigned the rest to Gillian (jokingly!)

Here’s to finishing the rest of this Project!