Keicia Chantel McIntyre
Operations Management MBAD 6223
Individual Term Paper
June 29, 2019
Introduction – The purpose or goal and scope of the paper. Motivation, significance, outline of the paper.
Background – We can deliver a much better service burning in your bones CIM Group formed in 1994 mission purpose focus values: integrity discipline and respect core competencies 900+ employees investing and improving and servicing communities better life of people in those communities add value (repositioning, rebuilding, community based focused) deliver better returns to our partners(investors) create a platform for people to join the company and improve. Cover all aspects working with communities, identifying assets, leasing, cleaning apartments, construction/development, budgeting, investor relations hired employees to support those efforts but were they truly the right enhancing communities and deliver investor returns are the goals/purpose. Growth/ employees were not the goal but a result of true goal competitive advantage(the team of people) of core values and expertise a copy focused externally but not internally you are important because of the task you have to complete 13 departments competitive advantage communities in
Contextual details like size of the hospital, region, calling population, internal and external reasons for this new service, inhibitors and facilitators of this new service, champions of this new service, type of managerial and budgetary support, etc.
The department had previously been intertwined with the Investments department but due to company growth it was decided that development should be its own department. With that split came the de
Story issues project scope goals and results
In November of 2016 I joined CIMs Development Department as an executive assistant to the two recently appointed principals. The department was rapidly growing, and they needed a Girl Friday. They had previously had department administrative assistants, but that role was more of a project coordinator and the demand on the team and principals, had made it difficult to stop and evaluate their work and processes. During my first week, I met with both principals and they said they wanted the same thing: to organize their lives and organize the department for efficiency. This need was also echoed from the department staff that I spoke with during that week. Many claimed they found it difficult to get the principals attention and approvals on project details, and that they were either late or did not show for their meetings causing projects to be extremely delayed at times. The frustration from the lack of organization and standard procedures that were not being followed in order to keep projects on time was clearly the first issue that needed to be addressed; so, I got to work.
The first order of business was to find time for the principals to be available to the team while at the same time completing their own required task as executives. This included an evaluation and revamping of their calendars, setting a standard for how and when staff meet with them, and keeping a track of all their task. Because they were different, they both responded differently to this new setup for their workdays, however with fine tuning, we achieved smooth sailing.
Successfully getting them organized granted me the opportunity to work on getting the department organized, and both principals were certain that leveraging the different technology programs the company already had in place would help achieve the level of organization the department needed. At the time, the department was tracking all their details on excel sheets or in the Yardi and Nexus systems that were used company-wide and all which had their own issues. Excel sheets were the most trusted because they were upkept by the individual. That means they had complete control of the data and had the most up to date details. However, excels can only be used by one person at a time and the integrity of the data can only be trust as far as when a person last updated their excel sheet. Since there was no standard procedure or protocol for how often data should be updated, it usually meant weeks or months before project details would be updated, typically because someone had requested the latest numbers and it was a rush to gather everything. Yardi was already being used to track project budgets and spent to date details and seemed like the ideal program to use for tracking project details. However, the numbers it tracks were only based on entries paid out and not predictions or currently be processed items. Also, after meetings with Yardi, the team realized that the program just was not flexible enough for their needs and the interface was not user friendly. Nexus was only good for issuing payments and tracking anything pending. It was a compliment program to Yardi but details like project data, funding availability, and timelines were not what the system was designed. The combination of excel sheets, Yardi and Nexus provided all the data tracked by the department but none of them were the ideal support system.
When asked to define exactly what they thought the program should be and do for the department, they actually had a list of four programs they wanted to implement, but at the top of the list was one program that could localized all project data ranging from staffing details to budgets and job codes. It had to allow for manual updates as well as automatic feeds from other software programs. It needed to be easily accessible from anywhere due to the teams often working on construction sites with limited internet access. Most importantly it needed to be user friendly. Something simple and visually appealing so that no matter who accessed the program, they could get what they needed. This technology program that they envisioned would need to be a game changer for how they gathered and distributed data. Ideally, in their minds, the program would be so successful that the development department would be the example for other departments on how to track and share data. It was a tall order, but I presented the current state of information as well as their vision to the IT department and they came back with a software program called the CAPEX tool. This program was a fully written and supported in-house server tool that at the time provided basic details project budgets, spend, and initial metrics from investments. The property management department had started to use it for tracking job codes and timelines, and the Technology department believed development could use the program as well. Because it was an in-house program, there were no real limits to the software. That provided the flexibility needed to create the system that service provided programs like Yardi did not allow. It was already being used for budget tracking and job coding, so it was assumed that adding in pending data and tracking variances could be done. There werent many reports coming out of the system, but there was another program that could be linked and support an export of the information and format into a report for distribution when requested. By the time the technology team finished presenting their recommendation, everyone was sold that this was the right choice. Like with all technology program though, there is a building phase that really brought to light more issues in the department.
Since the program was technically up and running, the first step was to build out the front-end of the system. Things like drop downs, consolidation features, rows, columns, naming conventions, fonts and color schemes had to be considered. This is where all the frustrations the team had previously mentioned about the principals started to come out. They did not want to participate in the build. I would schedule meetings for them to see what the progress done and they would tell me they didnt want to go. I would then print out screenshots of what had been developed and leave it on their desk for approval, only for the paper to get lost. And when I could get them to pay attention, I could rarely get them to agree. It was annoying to say the least and eventually the IT team began to looked to me to make the final decisions. I was transitioning from being an assistant to being a referee and systems admin. Once the interface was done, the next step was to setup a test property and see how the data flowed. Some details would be manually inputted while other details would be imported from Salesforce, Yardi and Nexus. The integration of the other programs was trickier than initially expected and during this phase is when both principals decided they were ready to pay attention and couldnt figure out why it was taking so long to implement. They expected because the program was already in use by certain departments that it would be up and running quickly, but we had barely begun to build and everything they wanted was going to take time. The integration had to be halted at one point and decisions made if all the integration was necessary. The question was could people go outside of this program for some of the information? Would it really be an issue if the project gantt chart could only be viewed in Salesforce if the dates were in CAPEX? Since Yardi is used company-wide can some of the details be left in Yardi and when needed pull from there instead of CAPEX? Those questions needed an answer and just as quickly as the principals came, they went away again, leaving the decision to me. So, I opted for less integration. To me it was a decision based on time, availability of resources and launching the program as soon as possible. The idea was anything that couldnt go in now in order to get the program out, would be tabled and possibly added in after the initial launch. The IT department agreed with me and we continued with a new goal focused on meeting the basic requirements needed to launch as soon as possible. Stage three was user testing. Now that we had a structure and the basic integrations setup, it was time to involve the teams to see if it worked. I chose three projects, two that were well underway and one that was just starting to participate in user testing and provide feedback. The project teams liked and did not like this system. It looked nice and had the basics, but the system was built based on the principals ideas and the standard format sheets the teams were using. What we found out was that the teams had their own ways and different sheets/formats for tracking their data. None of them were on the same timeframe for needing the report or issue bank draws, so even things like the dates on the columns for the financials were an issue. The feedback we received on day one of just introducing the teams to the system made it clear that this program could not launch any time soon. Also, the principals needed to be more involved because they didnt realize that the teams were not operating on the same standards. It was almost unbelievable that all three projects were in the same department, but the teams assigned to them functioned differently. We asked the teams to try using the system anyways and write a list of everything that they feel is missing or needs to be changed as they were using it so that we could take it back to the principals. Some of feedback were things we had chosen not to include in the initial launch, and some seemed more a personal preference than an actual need. After a month of user testing, we scheduled a larger meeting that I was able to get both principals to attend, and it was a disaster. After presenting the system, and how the data looked based on usage, they were not happy. Small things like wanting more high level and detailed filters so that they could see summaries of the projects and suppressing zeros were requested, but then there were large things like being able to click on a number and drill in to see all the invoices or contracts tied to it that were not part of this system. They walked out of that meeting feeling like we hadnt met their needs and wanting something they could use now, while we all sat there feeling like they had just wasted months of our time. Later, I met separately with them and tried to walk them through everything again only to become more frustrated as they blamed me for not communicating so that I understood their wants and needs. I thought to myself the audacity of these two. Two principals who couldnt agree on anything except that this system needed to be built and who for almost a year paid little attention to what was happening, and they want to blame me. It was doing work nowhere close to my job description and building a system that was supposed to help make this department best in class. But what could anyone do; the IT team took their feedback along with the teams that did testing feedback and started to make changes- iterate to success. In February of 2018, CIM Group acquired a company and all IT efforts were directed towards that integration. I left the department in October of 2018 and while two of the four programs they wanted have launched and are being used, that number one priority program has not launched nor updated.
So many errors were made in the effort to build this custom system for the development department. First, the fact that IT was working on three other programs for the department (a Contract Approval Form with Job Code Creation, New Salesforce platform for Development, and Updated Vendor Maintenance Form) was not the best idea as resources were strained to try and get everything done at once. It was hard to explain that IT was not solely employed for our department, so instead they worked tirelessly until the acquisition gave them a solid excuse to focus their work elsewhere. Second, during the blueprinting phase, we should have asked the project teams how they tracked and used their data. A system was built based on the executive perspective, when it shouldve been built based on the users. The user perspective brought an even bigger issue to light, which was while there was a template for project operating procedures, the project teams altered that template based on their personal preferences and projects. In hindsight before trying to implement technology programs we should have setup up the process and standards for the basic work. The technology would have been better received, understood and less of a hindrance if the standards had been set for the work without technological assistance. Third, the principals should have been forced to participate and provide feedback more often. For all I learned and gained from the experience, things would have gone differently if the principals had paid more attention. When managers fail to participate or provide feedback on projects like these, there are bound to be errors and lessons learned – What were the complex behavioral and people-related issues that prevented the new system from working as anticipated? What were the successes and why do you consider them to be so? What were/are some of the unanticipated outcomes or consequences? Why were they not anticipated? Going forward, is this new system/process sustainable? Why or why not?
Conclusion (1000 words) – 5.Learning issues: managerial learning issues; can these issues be transferred to similar contexts? Why or why not?