The Sim Project online simulation challenged the five members of group five to think

outside the box while making effective and efficient group decisions on how to install and

test a company network, based on the outcomes of previous rounds. Within the following

paragraphs, we sum up how project guidelines were adopted, we critique our strategy for

the game, we sum up the individual lessons learned and how they relate to respective team

members, we suggest ways our team might improve and finally list the top five takeaways

from this project.

The group decision making process was facilitated by the following guidelines:

Consensus: Decisions were only made if every group member was in support of the

choice at hand. This did not necessarily mean that everyone was in complete agreement --

simply that they believed the given decision was the best solution given the circumstances.

Disagreements: Opinions were heard on all issues before finalizing decisions.

Compromises were made until all members had formed an agreement.

Order: Issues were brought to the table according to overall difficulty and immediate

importance. The simplest problems were tackled first. This typically included assigning the

project manager to management projects, placing the software engineer in software-related

tasks, et cetera. Then, remaining individuals were assigned to open tasks. Finally, remaining

decisions were made according to current and future goals and requirements.

Strategy: All choices had to fit into our overall strategy. Though our general plan

changed over the course of the simulation, all decisions fit into the model that existed at the

time.

Adaptation: After each round of play, the team analyzed previous performance

results and made strategy changes accordingly. As with all decisions, this was governed by

consensus.

Meetings: Once a week, on Wednesday evenings, all members of the team would

meet to loosely plan out goals for the upcoming periods. These conferences were setup to

define general guidelines and decisions. Few decisions were ever finalized in these

meetings, so that we could tailor our strategies to round-by-round results.

 Absence: In the event of a member absence, decisions were still made according to

policy, but only after gaining permission to do so from the person in question. This happened

twice over the course of the simulation. In both occurrences, written permission to proceed

was gained from the absentee.

After experimenting in the first couple of practice rounds how the game would play

out and what would happen when certain strategies were used in the hiring phase, we

eventually settled on the strategy of trying to start with a very strong team to at least build

the basis behind our project management tasks. The downfall to this decision was that it

was very expensive in the first couple of rounds, and because we went for the most

expensive and experienced players, they were also in high demand. This high demand led

us to not being able to get our project manager, which caused a number of inefficiencies

and higher costs in the first round.

After seeing the errors that we were running into after the first two rounds, we

decided to take a mid level approach, trying to acquire staff members who were mid level in

their skills and experience, with the idea that we would not have to train these users, at the

cost of a little bit less efficiency. This strategy helped and panned out quite well when it

came to the overall success of the game, placing us in third place for most of the game.

There were two main caveats that we found when it came to the game and actions

we took. First, we found that after we sent our systems software engineer to user training,

with the theory that we might be able to have the person who designed the software, train

the customers that would be the main end users, the training didn’t actually take.

Therefore, it seemed like the $1800 we spent to train this person, did not help in the results

of the game and actually negatively affected our group because of the consistent 60%

efficiency that our software engineer had with this sort of task. Even with one on one chats

to try to get her to improve in her training, we still got the same results. This was quite

baffling because Clemencia was supposed to have a 94% work ethic which would more than

make up for her 67% interpersonal skills, while training was added specifically for her to
train and assist in the use of the system by customers. This added additional costs which

worked against us in the final rounds of the game.

The second caveat we found of the game was that it seemed to have been a very

technical simulation with very specific duties for members of each team, written by a not-so-

technical team of creators who didn’t seem to follow this model. The best example of this

was job roles of members of the teams did not match up to what they’re actual roles would

be in real life. Take for example the office engineer and the network design consultant.

Having two members of our team who are in the Networking and Systems Administration

graduate program, we can say with confidence that a network design consultant should not

be specifically tasked with only documentation, but should be able to install and test cables

and hardware as well. This was evidenced in the game, specifically round 12, when the

network design consultant had a 40% effectiveness and 79% efficiency rating, in a job that,

according to game creators, he was supposed to be most experienced and the best at.

Compare this to the results of period nine, where tasks done normally in real life, specifically

installing and testing cable, by a network engineer, were done effectively and efficiently by

the office engineer.

Overall, we felt that our strategy for the game was successful until about round 11

when we lost ground to be put in fourth place, and eventually end up in fifth place. Our

beginning strategy of building a strong foundation for our team put us in good standing for

the first part of the game, but the overall lack of efficiency and effectiveness by the systems

software engineer hurt us in the last two rounds. Added to other issues we ran into with our

Jr. Systems Analyst being only 50% effective and efficient as well as an unexpected budget

problem because of the inefficiencies mentioned previously, we did run into some minor

snags, but overall are happy with the decisions of our first 9 rounds. While the game was

slightly confusing on its overall strategy, we found it to be a great learning experience in

strategies which to use on project teams in real life.

 In the future, if we were to work on a similar project there are several areas we could

improve upon. The main areas of improvement are time and cost estimation, resource

allocation, budgeting, and team dynamics.

We grossly underestimated the cost of the overhead. Instead of hiring the most

costly employees, we could have hired mid-level and spent a minimum cost training those

employees to better perform. Some employees were more efficient than others. Those

who were inefficient ended up costing more money as well, as they spent more time

completing tasks. Our Jr. Systems Analyst, Jonathan Norseworthy, was particularly

inefficient.

Our resource allocation was also lacking. We did a poor job of allocating the proper

resources to a task. We did split tasks on occasion, but kept that to a minimum, as this

actually can lengthen the time it takes to complete a task. Still, less splitting could have

helped us to be more efficient (Gray, 250).

A time-phased budget would have helped as well. We did not look far enough ahead

in the project to see that we would go over-budget. Had we done so, and budgeted

accordingly, we could have placed better overall in the competition.

Another lesson learned is to pick an efficient and effective project manager.

Although Della Starliper was effective, she was never more than 78% efficient. With such a

workload, greater efficiency was needed. Perhaps some more training (time management)

would have helped. Additionally, it was noted that Eugene Yule (MIS Manager), and

Moshihiko Chikanatscu (Sr. Systems Analyst) were not efficient, leading the group to

question the effectiveness of Della. Although her interpersonal skills were 81, perhaps she

was ineffective at properly motivating the team. We did attempt to boost morale with pizza

parties and milestone celebrations, but this seemed to have little effect on the overall

progress we made.

Another issue we faced was that the longevity of the team was compromised. We

hired/fired quite frequently, instead of training someone in some skills outside of their job

description. We failed to take into account the power of group dynamics. Our simulated
team never had a chance to gel, as new faces were coming and going nearly every other

period. In future projects, we would keep some more consistency. This would likely lead to

greater success.

The SimProject simulation game allowed our group to view the situations and

problems that arise in most projects. Our group was able to track the evolution of a long-

term project in a short amount of time. Common themes and concepts throughout the

simulation were: project scope, cost, asset allocation, and human factors. After completion

of the simulation five dominant takeaways surfaced.

The first prominent takeaway from the simulation was that developing long term

goals and group milestones helped coalesce group decisions and facilitated group debates.

Our team consisted of five group members each coming from different backgrounds. By

creating a common goal it allowed our debate and conversations to be focused around a

central theme, which kept the meetings productive and on track.

The second major takeaway learned from the simulation was that consistent

communication with group members proved to be beneficial in managing risks and

overcoming unplanned outcomes of the simulation. Meeting often allowed the group to

discuss the implications of certain decisions and tasks. Allowing us to better plan and meet

pre-defined goals. Also when outcomes did not turn out as planned communication allowed

us to avert additional complications and mitigate the current ones.

The third learning point was that there were a lot of unforeseen uncertainties due to

the nature of the simulation. This factor was at first challenging but the group was able to

develop processes and eventually able to plan better for the unknown. Uncertainties often

show up in projects in many different forms, this aspect of the simulation allowed the group

to see the many challenges of projects in the real world.

The fourth takeaway was that using tools like Microsoft Project greatly helped the

group to plan and allocate resources. Using Microsoft Project was one way that our group

was able to plan for unforeseen circumstances. It showed the entire life of the project and
the dependencies of the tasks. Our group was able to better assign resources to task and

allocate the amount of time spent on them.

The fifth and final learning point from the simulation was that matching tasks with

employees’ strengths was a challenge, sometimes resulting in inefficient task completion

and extra costs. Although this learning point was further complicated due to the fact that

this was a computer simulation, in the real world this can also be a challenging task. Our

group was eventually able to define a set of parameters that we thought represented an

efficient employee. We were then able to better allocate resources to tasks.

Group members gave their own personal goals and how they relate to this game in

the following section.

[Joseph] Upon graduation, I will be joining a Fortune-500 company as an IT Analyst.

My career in this company will be given two possible paths – Technology Management or

Engineering. Though I hope to follow the engineering path, the lessons in group dynamic

management learned from this project will still help to advance my career and enhance the

possibility of success in my future projects. It stands as a necessary skill for any field,

regardless of an individual’s title.

[Patrick] My career goals mainly revolve around becoming a network or systems

administrator, hopefully in a smaller company at first, but eventually moving to a large

company which may have more opportunities for learning new techniques and career

advancement. This being said, the game relates to my career goals because of the constant

growth of small business and projects usually revolving around a sort of network expansion

to support more users, a bigger facility, or new, more efficient software. With any sort of

project involving technology, there is always a need for a project manager to help the

project run more smoothly and keep track of the success and happiness of the stakeholders.

With the experiences learned in this game, I learned that the paper work side of things –

documentation of what is being done, tracking of costs, keeping track of how much time

each person is using and how that related to cost – is also a very important factor in addition

to the project itself. I think I am better prepared to take on a project similar to this
simulated one and lead it to being a project which could be part of an overall large and

successful project.

[Erika] As a scientist in an engineering role, I am pursuing my MBA in order to

transition to a more business-oriented role. The majority of my work is currently performed

in in-house teams, and will expand to encompass more groups both internal and external to

my place of work. The simulation game was a good opportunity to see how group dynamics

can affect efficiency and success of project teams. In the future, it will help me to evaluate

a group as a whole, rather than focus on the strengths of individuals, hopefully leading to

more success.

[Ryan] My career goals are pretty much the same as all the other technology majors

in the group. I eventually want to pursue a career as a network security administrator. This

simulation showed me the complex nature of implementing technology systems.

[Andre] As a scientist transitioning from academia to industry, where almost all of

mine work is expected to be performed in teams, the class and the simulation game gave

me conceptual understanding and a hands-on opportunity to further improve my

interpersonal skills.

Resources:
1
Gray, C.; Larson, E. Project Management. 4th ed. 2008.