Monday, March 31, 2014

MS Project

MS Project Memo:

                Recently several employees of our company have asked about the potential use of Microsoft Project in our work place. The memo is to address that question as well as provide some potential insight into the Microsoft Project package for those in our company that might be unfamiliar. Before addressing the option for adding Microsoft Package to our software suite lets first begin with some background.

Techsoup Defines Microsoft Project as:

"The ancestor of project-management tools, with powerful functionality that is beloved by many professional project managers but might be overkill for small or even medium-sized teams. As opposed to many of the other tools on this list, Microsoft Project is strongly focused on defining a detailed plan up front, and then updating the plan over time to account for actual time spent and actual dates hit. It assumes that there will be a central project manager who is overseeing the plan — and that this manager will have a number of hours per week to devote to keeping the plan up-to-date. But with that investment, it offers powerful ways to see the effects of changes to your project, the allocation of your team members, and more."


One of the points to highlight from the above passage is that Microsoft Project is strongly focused on defining a detailed plan up front. This portion is significant and cannot be underrated. The impact in planning and being able to utilize a software to organize and detail plans for a project is huge. We can significantly reduce potential errors, wasted time, and maintain scope over the long term by planning ahead. These impacts can result in significant savings, both literal or in the cost avoidance category.

To further stress the point of the impact with planning the following two sections from Rita Mulcahy’s PMP Exam Prep 8th Edition are useful:





Now, while I discussed the impacts in a positive way, this is not to say that Microsoft Project is the answer to our company. The impact in business that I referred to above is utilizing a software. MS Project is expensive. Some basic procurement searches show that MS Project would cost between $500 and $1000 per user depending on the level of support required. Also, the software to some degree complicated for many of the lower experienced project managers in our company. Equally, more experienced users tend to dislike the constraints of MS Project.

The following is some interesting excerpts from Chartgantt.com

“Many first-time project managers find MS Project too complex to learn and understand. Many of the biggest features take years to get down pat and work with. This complexity usually leads to them looking for less complex approaches to establishing a Gantt Chart or spreadsheet view of their Project planning data.

Knowledgeable project managers are becoming increasingly disappointed with MS Project and its many contrasting implementations. Someone will be used in MS Project enterprise edition to manage projects over an organisation. The architecture of MS Project provides a much greater degree of rigidity than many project managers would like."


As a company trying to do the best for our shareholders and customers alike, we need to aim for the products that make sense for our needs. The positive impact of a project management software cannot be understated, however, I would have to argue that with the costs and resource constraints MS Project wouldn’t have a strong linear impact that would justify the move. We should aim to explore alternatives such as Project Libre (which openly bills itself as a replacement for MS Project), GanttProject, BaseCamp,  Central Desktop and ToDOList.

Regards,

AJ Varghese

For Additional Reference Please see the below:

Basecamp
Easy to use, and widely popular, Basecamp might well be a good choice for teams without complex needs. It's focused on supporting the needs of geographically remote teams, and offers strong functionality in document-sharing, document collaboration, shared calendaring, and notifications when something changes. It's considerably more limited in the realm of planning and even task-management, however. For instance, there's no ability to create dependencies between tasks, see a Gantt chart, or define a calendar deadline for a task. It offers a number of different levels, starting at $24/month to manage up to 15 projects with unlimited users.

Central Desktop
Central Desktop is conceptually similar to Basecamp, but is somewhat more powerful. It's particularly strong in integrating with email-based workflows. For instance, you can not only share documents, calendars, tasks, and get email notifications of updates, but you can easily copy a Central Desktop email address to have emailed comments automatically entered into the appropriate place in your project files. It has a free version that supports up to two workspaces and five users, or otherwise a number of different pricing schemes, including a $25/month plan for up to 3 workspaces and 10 users, or a "community plan" that's simply $3 per user per month. Ask about additional nonprofit and charity discounts.
If Basecamp and Central Desktop look interesting to you, there are a number of other web-based, collaboration-focused tools in the same vein. For instance, you might want to consider GoPlan, DotProject, or Zoho Project.

DreamTeam for Salesforce
Those that are using Salesforce to manage their constituents should consider DreamTeam, which is free to nonprofits and charities for up to 10 licenses. This tool straddles the gap between Microsoft Project and the collaboration-focused web-based project-management tools, with solid support for project planning and Gantt charting as well as the more typical collaboration and document-sharing functionalities.

And

Project Redstreak Memo

Memo: Project Red Streak Development

                As part of the project team for Project Red Streak, we feel it is imperative to keep management in the loop regarding our considerations. We have constructed the initial development plan given the high level criteria. With a start date of 1/1, the project is projected to take 271 calendar days. Our current expected finish date is the end of September (approximately 9/29). The time differences are given holidays, weekends, and workflow estimations. Though the project will start 1/1, it will not actually start till the following day due to the holiday schedule. Additionally, there is a total of 272 work day items, but the reduced schedule is due to the overlap of work. We expect that due to the nature of the workflow we will be able to complete all work in this time frame.

As part of this note, please find two attached supplementary files for illustration. The first is a GANTT Chart and the other a Network Diagram. I will also provide them in screen shot format for easier viewing below the note. For those who may be unfamiliar with GANTT Charts and Network Diagrams please refer to the following items that outline definitions as advantages and disadvantages of each by ProjectManagementGuru.com:

“The Gantt, or Bar, chart is the most common schedule format used on projects. This format is excellent for tracking progress or activity for tasks once they have been scheduled. In the Gantt chart, every task is represented by a bar of a time line chart. The left edge of the bar is located at the time the task is planned to start and the right edge of the bar is located at the time the task is planned to end. As the project unfolds, the edges of the bars are often modified to reflect when the task actually started or ended. This format creates focus for tracking progress because it is clear to see whether a task should be completed, underway, or pending at any given time. The Gantt chart is used for daily/weekly tracking of project progress. It is easy to use and maintain. It has become the most commonly used project schedule chart because of its simplicity and the focus it creates when tracking the project. If the task estimates are relatively accurate, this is the preferred format. However, when task duration estimates are not accurate - either due to uncertainty in the amount of work or uncertainty in the resource availability - the Gantt Chart will be a frustrating and counterproductive scheduling tool. In those cases I recommend the use of the Network Diagram.

The Network Diagram is essentially a flowchart of the project tasks. This format is a foundational technique for several analytical techniques. The network is created by determining predecessor and successor relationships and connecting the tasks based upon those relationships. This technique will create focus on the handoffs. In a complex project with many organizations/individuals involved, this technique can provide guidance as to who is the internal customer for each task. The technique is often viewed as a foundational technique since most of the advanced analytical scheduling tools start with the Network Diagram. When task durations are uncertain, the Network Diagram is often a better technique to use than the Gantt (bar) chart. The Network Diagram shifts the focus for uncertain tasks from arbitrary start and end dates to completion of the work and a handoff to the next task/activity.”

Utilizing the GANTT Chart and the Network Diagram we can easier see some significant items including the critical path and work flow. Our critical path is through items 2,3,5,8,9,10,11,13, and 14. Please see the Network Diagram items in pink for a complete reference. We will find the bulk of our float in the middle of the project. An example of which is with Detailed Marketing Plans (item 6) and Manufacturing Process (item 7). Items 8 and 8 will take 50 days and 10 days, respectively, to complete before the next task. While the depth of the project requires our critical path to be highly maintained we can find opportunities if delays exist early on.


Please note that a follow up will be distributed shortly regarding MS Project and business impact.

Regards,

AJ Varghese

Supplementary Material:

GANTT Chart and Network Diagram Definition Source:
http://www.projectmanagementguru.com/scheduleplan.html

Select PMI Definitions: 

Sourced from : doit.maryland.gov/SDLC/.../Network%20Diagrams.doc

Schedule network analysis, as defined by the Project Management Body of Knowledge (PMBOK), is a technique used by project managers to analyze schedule information and generate realistic and optimal project schedules.  This analysis should be performed upon completion of the draft schedule and network diagram and after each schedule update.  Schedule network analysis involves:

·         Identifying the schedule impact of task dependencies
·         Identifying critical path tasks and understanding the impact of the critical path on the schedule.  Software tools such as Microsoft Project automatically display critical path tasks once project information such as tasks, dependencies, and durations are identified in the tools.
·         Analyzing the effects of schedule constraints and externally imposed dates
·         Understanding which tasks can experience delays without delaying the overall schedule
·         Conducting “what if” analysis of various activity durations (for example, what if the testing activities take twice as long as is currently planned?)
·         Assessing resource allocation and leveling to prevent resource over-allocation
·         Assessing fast tracking or crashing options to ensure optimal schedule performance

Analytical Techniques:

PMBOK describes the following techniques to perform schedule network analysis.  For more detail regarding analytical techniques, which provide valuable information necessary for effective schedule definition, see PMBOK, fourth edition, Section 6.5.2.  Most scheduling tools include features that allow utilization of these techniques with minimal effort.

·         Critical Path Method – The critical path method calculates the longest path of planned activities to the end of the project – the “critical path” – and the earliest and latest date that each activity can start and finish without extending the project.  Any activity delay on the critical path impacts the planned project completion date.  A network diagram visually conveys the critical path.  This visibility into the critical path allows project managers to prioritize activities and take appropriate corrective actions to meet schedule deadlines.

An understanding of the critical path also allows project managers visibility as to which schedule activities are flexible – that is, those activities that are not on the critical path.  By looking at a network diagram, project managers can determine when they have float or slack, which is the amount of time that any given schedule activity can be delayed without causing a delay to the start date of subsequent activities (free float) or to the project completion date (total float).   Knowing when a project has float allows a Project Manager to understand what tasks may slip and by how much before they have an impact on the project schedule. 

Project Redstreak Criteria:



GANTT Example (for easier viewing):



Network Diagram Examples (for easier viewing split into 3):





Saturday, March 29, 2014

PREP Case preparation and Reflection

The Puerto Rico Education Project System Development In An Island Paradise

Preparation Notes:

Puerto Rico has a population of four million on an island of only 3,400 square miles. It is a U.S. possession, and its citizens have full U.S. citizenship, but the people have chosen to continue as a commonwealth rather than as a state of the Union. This means that they receive protection and govern­ment aid, but they are not required to pay Federal income taxes, and they have considerably more governmental freedom than they would have as a state.

Puerto Rico is more densely populated than any state of the U.S., and the proportion of people below the poverty level is much greater than on the U.S. mainland.

The Puerto Rico Education Project (PREP) resulted from a contract negotiated by a division of a large U.S. company (here­after called USCO) with the Puerto Rico Department of Education. The contract, funded by the U.S. government, specified the installation of a large mainframe computer and associated hardware, the design and implementation of a system to assist the Department in evaluating the results of education programs funded by the Federal government, and development of a large database containing data about all the students, teachers, and schools throughout the island. The cost of the hardware was about $5 million. It was expected that system design and devel­opment would require another $10 million, consisting primarily of personnel costs, and would take three years to complete.
At its peak the project staff would consist of about 25 people, of whom twenty would be relocated from the U.S. and the other five would be local hires.

As the contractor, USCO agreed to perform the following:

  • Design and implementation of methods and procedures for the collection and storage of educational base-line data.
  •  Design and implementation of data handling procedures.
  • Design and development of mathematical models and techniques to permit the continual assessment and evaluation of educational programs.
  • Design and implementation procedures for the maintenance and updating of data in the base-line framework.
  • Training of Puerto Rican personnel in effective use of the system.


Project Staffing and Other Initial Decisions

Client perceptions of the success of prior projects performed by the company was one of the most important factors in obtaining new business, so client satisfaction was a primary objective, and quality control was closely monitored.

It was clear to USCO executives that the Puerto Rico project should be classified as a domestic assignment. Puerto Rico was not a foreign country; it was part of the U.S., so the international policies did not cover PREP. This was to be administered as a domestic off-site project, the same as if it were in Oklahoma or Illinois.

There were to be three levels of management: Level 1, the Project Manager, who would report to a USCO Vice President in headquarters; Level 2, the System Design Manager, the Programming Manager, and the Administration Manager; and Level 3, several first-line managers reporting to the System Design and Program­ming Managers.

Next in line was Gary Johnson, who had just completed a major project at the Pentagon and whose expertise was in hardware. He had managed large numbers of people in complex military projects, although none had any connection to education. Johnson had never been involved in an off-site project, but this one appealed to him partly because he saw this as an opportunity to aid humanity and alleviate poverty in some small way.

This was to be a three-year project on a remote island, so the families of project personnel would be moving there with them. The moves were expensive for the company, so each employee selected was required to agree in writing that the family would commit to staying in Puerto Rico for three years. There were, of course, provisions for leaving sooner for valid reasons such as illness of the employee or a family member. There were also provisions that virtually guaranteed that the employees could count on continued employment with USCO for at least 18 months after completion of the contract; in jobs of equal or greater status and compensation.

The staffing plan called for a small team of systems analysts and planners in the first year, building up gradually to a peak of 30 people by the second quarter of the second year. Program­mers would not be needed for the first nine months or so. The mainframe computer was being custom-designed and would not be available until then, and there would be no defined programs to write until a substantial part of the system design work had been done. However, a large U.S. Army project had just been completed at the Pentagon that had employed a number of young, bright program­mers. Since it had always been difficult to get good programmers when they were needed, Johnson felt it prudent to hire seven of these programmers and take them along to Puerto Rico. Smaller comput­ers could be made available for them to work with, and surely there would be important tasks that they could perform.

The Move to Puerto Rico:

It was becoming increasingly evident that conditions in Puerto Rico were considerably different than had been expected. Living costs were actually about 15% higher than in the U.S., particularly at the supermarkets, which had to ship most products in from the U.S. and other countries. Another problem that surfaced immedi­ately was schooling. There were about 15 school age children among the families in the project, and the school term was starting shortly after their arrival. Belatedly, it was realized that the basic reason for the PREP project was that the school system on the island was mediocre; teacher and principal salaries were extremely low and facilities were old and in poor condition. Some schools did not even have electricity. Many of the windows were metal louvers rather than glass, and had to be closed during the frequent rain showers. At such times, the pupils had to sit in the dark until the rain stopped. Also, the language in the public schools was Spanish, which none of the project children spoke. It was obviously necessary that they attend private schools, at an average cost of $2500 per semester per child. In a foreign assignment, private school would have been assumed, but since this was a domestic assignment it was decided that a schooling allowance was out of the question; it might have led to demands from employees on other projects that USCO pay for private school tuition. Instead, for each employee with school age children, salaries were raised just enough to cover the schooling costs. It was understood by the company and by the employees that this was a temporary raise and would be rescinded when they returned to the U.S. mainland. It took several months for agreement to be reached on this issue, and it was the source of considerable bitterness.

The most serious morale problems were with the spouses of the employees. Most families had only one car, which the employee needed for the trip to the office. Many of the wives were stranded at home most days, with small children to care for, and neighbors who spoke little or no English. They were also disturbed by the slower pace of life as compared to the U.S., which they derisively termed the “mañana” philosophy, especially when they needed some service professional such as a plumber or painter to come to the house. Still another problem was a lack of telephone service; for the first year of the project, most of the families were not able to obtain a phone. Two women gave birth to babies and had no telephone service during the entire pregnan­cy.

Dolores Valdez, the secretary who became Administration Manag­er, proved to be competent at finding good office space. Banco Popular, the largest bank on the island, had just completed a new building in Santurce, in the heart of the business district. Dolores leased the entire 17th floor in that building, nicely furnished and with a panoramic view of the city. However, she had never managed people, and she did not like to get involved with the employees’ personal and financial problems. She pre­vailed upon Johnson to make those decisions and fight those bat­tles, so he had little time for actually running the project. This was a source of increasing frustration for him.

The PREP Project

The data collection volumes to be dealt with in this project were quite large. The Department of Education operates schools throughout the island. At the time of PREP, there were more than 2,000 schools, with 25,000 teachers serving nearly 800,000 pupils. Among all school systems in the U.S., only those in New York City and Los Angeles are of comparable size.

In their pleasant office facilities the project managers were beginning to recognize some of the problems that lay ahead. They were still involved with getting their families settled, but what had seemed to be a comfortable project schedule was looking increasingly tight. The system to be developed was still not well defined, but the volumes were staggering to contemplate. Burt Garfield analyzed the data entry requirements: for the 800,000 record Pupil file, assuming only 40 characters per record (much less than the U.S. Office of Education wanted), data entry alone would require three hundred person weeks of effort. This could not commence until forms and instruc­tions were designed, distributed, and returned, and it would have to be completed by early spring so that files could be built for the programs to analyze. Although this was a simple calculation, the contract estimates had not taken the data entry effort into account. The scope of the project had to be cut down; it was decided to collect data on only 200,000 pupils and to postpone the rest until the second year.

The system was intended to have a planning and research focus, since its main purpose was for program evaluation. To aid research, it should be possible to select a representative sample from a large population on demand, and software should be available to perform statistical calculations on the data. As a planning tool, the system should readily provide data relating to trends in pupil mobility, performance problems, inadequate facilities, etc. The system was also expected to offer advantages to teachers in the form of improved and timelier reports on pupil performance, such as test results and pupil profiles.

Progress was disappointing, however. Some of the problems that had been encountered included the following:

·         The programmers, who had been included in the initial contingent under the rationale that they might be difficult to find later, were unhappy. The large mainframe computer for which their programs were to be written would not be delivered for several months. There were useful tasks to keep them busy, such as writing specifications for programs, and smaller computers were available for some of the tasks, but they were anxious to write and test the actual code for the main system.
·         Data for every pupil and every teacher in one quarter of the 2,000 schools was to be collected. The data collec­tion procedure was designed so that each teacher filled out the data form for each of his or her pupils. In preparation for this, the project systems analysts inter­viewed principals and teachers in a number of schools. None of the systems analysts spoke Spanish well enough to communicate in that language. It was found that, although most of the teachers could understand basic English, they were having a very difficult time under­standing the procedure, which involved some fairly techni­cal concepts for which they did not have the vocabulary. Some of the analysts suggested to Gary Johnson that he hire two or three young Puerto Rican college graduates as analysts; they would be able to explain the concepts to the teachers in their own language. This suggestion was resisted by USCO officials, who felt that the language problem had been solved by the provision for Berlitz courses.
·         The data collection forms were printed and ready, but there was no satisfactory delivery service for transport­ing them to the schools, especially those located in the remote areas of the island. It became necessary to rent vans and for the analysts them­selves to deliver the forms, and later to pick up the completed forms from the schools. This was quite dangerous, because the rural interior areas were mountainous, the roads were narrow and sharply curved, and often covered with slippery wet leaves. Fortunately, the deliveries were completed with no accidents.

In spite of the problems, substantial progress was made during the first year of the project. The mainframe computer was finally delivered and the programming trips back to Washington were terminated. Programming and testing was behind schedule, but not as much as it had been a few months before. Dr. Hamill and the other Department of Education officials were pleased with the system design and with the capabilities they would have for evaluation, although they regretted the limited database. The curtailed but still massive data collection effort was completed successfully, and forms were shipped to a U.S. data entry service.

Most of the employees worked hard and conscientiously, but morale was at low ebb and this was adversely impacting produc­tivity. USCO executives were concerned; costs were higher than budgeted, and some important deadlines had slipped. A number of executives had visited the project, and most of them had been deluged with complaints from employees. In the ninth month of the project, Tom Ballard, who had just returned from a European assignment, was asked to conduct an investigation to determine what needed to be done to get back on schedule and on budget. He was also to take over direct responsibility for the project, so Gary Johnson now reported to him. Within limits, Ballard had authority to make any personnel and organizational changes that were needed.

From his one-on-one discussions with each employee, Ballard knew that about two-thirds of them had an intense desire to be sent back to the U.S. They, and especially their family members, were unhappy with living conditions, with the schools that their children were attending, and with USCO. Their poor morale had an adverse effect on productivity. Some employees spent a significant amount of time on the telephone with their spouses, who often called to complain about home problems.

The other seven employ­ees had a completely different attitude; they and their families thought Puerto Rico was a fine place to live and a wonderful opportunity to meet people from all over the world. They had developed warm friendships outside the company and had learned to love the outdoor activities that were available, such as golf and snorkel­ing. These seven definitely wanted to stay, and they included some of the most productive members of the project. There was considerable animosity between the two groups, which was also hurting morale. Some of those who wanted to leave were also excellent performers, and losing them would be a difficult problem at first, but some of the most complex programming was near completion. Ballard was fairly confident that the project could be implemented satisfactorily with the nucleus of the seven, who wanted to stay, plus eight to ten young Puerto Rican programmers and analysts who were available for hire. Some of these had already worked on the project on a part-time, temporary basis, and had proved to be fast learners and creative analysts.

However, he was not at all convinced that it would be a good idea to let all those return to the U.S. who wanted to go. His orders were to use this option only as a last resort. Finding jobs for all those sent back would be a major problem, since some other large projects had recently been completed. His biggest concern, though, was the precedent that would be set. After all, these people had volunteered for the project, and had willingly, even eagerly, signed up to stay for three full years. Based on this commitment, the company had invested substantial resources in transporting them and their belongings to Puerto Rico, and large amounts of executive time in responding to their personal prob­lems. The expense of sending them back was also considerable. By no means had this investment been recouped, and since meaning­ful U.S. assignments were scarce, they would not be nearly as productive in the U.S. as they would have been by staying with the project. It was an important project, too, with potentially great long-term benefits for the children of the island; were these employees unaware of that? The company’s policy guaranteed them a job in the U.S.; were they taking unfair advantage of the company? Should they be allowed to break commitments without any penalty? Certainly USCO’s policies were poorly thought out, but did not the employ­ees have some responsibility? Shouldn’t they have realized that living in Puerto Rico would be different than in the U.S., and that it was not an “island paradise?” Why did some employees love it here while most did not? Had the Puerto Rico-haters given the island a fair chance? Did their attitude that they did not like cultures different from theirs become a self-fulfilling prophecy? As Tom Ballard entered the dining room, he could see that two groups were separated, with those who wanted to leave on one side of the room, looking angry, and the others with serious but expectant expressions. He was still weighing the alternatives as he strode to the microphone.

Reflection:
          
          JAGR Consultant group was tasked with a difficult charge. Evaluating our companies position, the current standings of the PREP, and offering a set of solutions towards a failing project is never easy. But, that is why we hired them. The consultants did a good job capturing the essence of PREP related business evaluation with the following slides:





The first piece was important cause it is a reminder that our primary objective is client satisfaction. The second component illustrated what I thought was an essential piece for leading to a decision. 

The team from JAGR recommended keeping the seven employees that were happy and hire Puerto Rican programmers. 



I fundamentally agree with his plan but think that it is lacking in full depth. There are some additional points to recommend and realize.

The first piece to really understand is that the project was set to fail by management. As members of the board, we have to cognizant of internal mistakes so that we don’t repeat them.

The following is one area where we failed:

“John Piersall, the division Vice President for Personnel, was dispatched to San Juan for three days to determine the need for special policies. His mission was to evaluate whether language would be a problem and whether there was a difference in cost of living. He stayed at the Caribe Hilton, a pleasant hotel in an exotic setting on the beach. Although he expected to find that most people would speak adequate English, he was pleasantly surprised to find that the desk personnel, the bellhops at the hotel, and the people running small shops in the beach area had an excellent command of the language. He was not able to communicate with the maid who cleaned his room, but he reasoned that the teachers and princi­pals with whom the PREP employees would be dealing were educated people and would have no problems with English. To evaluate the cost of living, he discussed costs with a wealthy friend of his who was the manager of the San Juan branch of Chase Manhattan Bank. This individual had a beautiful home maintained by three servants, and he had not noticed any difference in living costs as compared with the U.S. He did mention that there had been some recent agitation by the independistas, a small fringe group who wanted Puerto Rico to declare its independence from the U.S., but he felt that the great majority of the people wanted to remain part of the U.S. and would not be influenced by the independistas. Based on Piersall’s report, it was decided that PREP could be administered as a standard domestic off-site project, without special compensation or other new provisions."

Gary Johnson didn’t have a chance to succeed because the initial planning stages were wrong. This is not to say that I am absolving him or any of the other employees of their personal responsibilities to the company and the project. The point is that as leaders we have to recognize accountability is a two way street. We have to be accountable for our actions. Mistakes are as serious as the results they cause, and in this case we are faced with a real serious negative result.
Having set the stage for accountability, our course of action should be to steer the project back towards a successful path. We should meet with the our customers first. They are currently happy and we want to keep it that way. While we won’t outright say our project is failing, we should take the accountable approach and try to realign some goals now that we have more current data. We wouldn’t want to endanger the welfare of the children’s education just to meet a deadline. If we can afford to take some time to regroup, we can at least plan more carefully and really assess our current position. We can’t know how to get to where we want to go without first knowing where we are. In this effort, we should also recognize that the current deadline needs to be reassesed.

Once the position is really understood then we can go on with the consultants plan to keep the seven employees that were happy and hire Puerto Rican programmers. We want USCO to have more control over the project and try to make the situation better for all involved. The timeline for the project should also be revisited based on where the project is now. Deadlines were missed, so the remaining aspects of the project need to be re-planned so that new deadlines can be put in place based on the new project direction that will be taken with Tom Ballard as the project manager. After revisiting the project deadlines, this will allow USCO to increase customer satisfaction because they will meet the new deadlines with proper planning. Ultimately we want success and that will begin with realistic expectations, the right employees, and support from management across the board.



Sunday, March 23, 2014

Ubuntu - Potential Impact

Memorandum: Ubuntu.

                This memorandum is to discuss a recent topic of the potential use of Ubuntu in our business. For those unfamiliar with the topic at hand Ubuntu is a free complete desktop Linux operating system. “Ubuntu” is a noun from a South African language that translates into “a quality that includes the essential human virtues; compassion and humanity”. While we are discussing Ubuntu and its impact on our business, the philosophy can sound difficult to grasp as business isn’t usually associated with compassion and humanity. We, however, strive to develop our business practices to maximize profits but still maintain our humanity.

“The Ubuntu community is built on the ideas enshrined in the Ubuntu Manifesto: that software should be available free of charge, that software tools should be usable by people in their local language and despite any disabilities, and that people should have the freedom to customize and alter their software in whatever way they see fit.”


Ubuntu as an operating system has a potential impact on business. One case study illustrates how Capgemini, a business process outsourcing company, changed their IT infrastructure with Ubuntu. The following excerpts illustrate some of the impacts:

To realise its vision, Capgemini BPO designed and built an IT solution known as the Model Delivery Center (MDC) thin client concept. By eliminating the need for local infrastructure and applications at BPO offices worldwide, the thin client concept has improved Capgemini BPO’s efficiency, simplified management and enhanced the end user experience. What’s more, the hybrid thin-client approach means data remains on customers’ servers at all times, ensuring high levels of data security.

A standardised, global IT platform using Ubuntu Capgemini BPO has created a standardised, global IT platform for reliable, secure, cost-effective service delivery. “Capgemini’s MDC thin client concept concept shows how Ubuntu can help organisations replace disparate infrastructure globally by providing a high performance and simplified alternative” says Jane Silber, CEO at Canonical. “Ubuntu is lean, simple to customise, secure, easy to use and constantly available to provide the best possible end user and customer experience,” she adds, “and it is delivering great results for Capgemini’s BPO.”


The impacts described above such as reliable and cost effective service delivery bring up an interesting point towards its potential use in our company. We currently pay Microsoft a large licensing fee for our systems. Theoretically, switching to Ubuntu would save us a great deal of money. Reducing our operating expenses could help increase our profitability via investment opportunities.


However, while the preceding data suggests that Ubuntu would be great, I am uncomfortable with the idea of switching our entire infrastructure. The case illustrated success but the nature of Capgemini’s business and ours are very different. I have to look towards the greater good of the company as a whole and while Ubuntu may save money in terms of licensing costs, the risk of an operating system change on the company could be disastrous. Our profitability has come from stability. Changing on a magnitude of this scale could be difficult for many of our staff to handle. This is also a change that doesn't currently achieve a purpose that is in line with our current objectives. It may be worthwhile to examine the O.S. change in smaller groups of the company where it may make operations easier. I am open to hearing any well-presented ideas on the matter but currently am uncomfortable with suggesting to replace our current operating systems across the company.

Friday, March 7, 2014

Accenture Prep and Reflection

Accenture Case Preparation and Reflection.

Preparation:

In 2001 the Anderson Consulting separated from its parent company Arthur Anderson and rebranded as Accenture.

The CIO, Frank Modruson, from 2002 onwards, had the task of replacing Arthur Anderson’s legacy systems.

Decisions lay with a few possible options:
  •          Continue managing platforms with a decentralized approach?
  •          Use a mixed approach, where the same standard applications run throughout the enterprise but managed independently within offices?
  •          Use a one-firm approach, where there is a centralized implementation of critical systems with all offices connected to a central platform?


In addition to the above choices, a decision had to be made with whether or not the firm retained a “cost center” concept or should it regard IT as a service provision center that generated measurable value for the organization?

History:

Arthur Anderson was founded in 1913 to meet the requirements of tax regulations. In 1954, as the company expanded around the globe, the company differentiated itself by offering consulting. In 1989, the company split into two entities – one focusing on consulting and the other providing traditional audit services. In 1997, an arbitration began about separating the consulting division from the financial audit division. In 2000, the agreement was reached that the consulting division would pay 1 Billion dollars to the audit firm and give up its name in exchange for independence. In 2001, the company rebranded as Accenture via a 175 Million dollar campaign. Accenture IPO’d in 2001 and raised 1.7 Billion dollars.

Selecting a Platform:

Best of Breed aka One-Platform approach.




Managing:

The company’s 600 global and 1500 local applications would be too complicated to manage on multiple platforms. A single vendor approach would hopefully reduce costs. Microsoft was chosen as a partner. SAP was also chosen as the worldwide application for finance and HR. Hardware was also reduced to a few partners such as HP for computers and servers and Cisco for network related issues.

IT Like a Business:



Accenture was born during tough times. The DOT-COM bubble had burst and the ramifications of 9/11 would be pervasive. Accenture would continually have to seek operational IT cost reduction. Outsourcing was one of the fundamental approaches to cut costs.


Culture Shift:


Reflection:

Memorandum: Accenture/COBIT Consulting Reflection 

When I originally found out that we were going to bring consultants to discuss COBIT as an option I was skeptical of what the worth of the presentation might be. The skepticism had nothing to do with the consultants, concept, or consult charge but with the consultation expectations. After all, we are a consulting firm, the level of excellence we should expect should be high if we are seeking outside consultants. Despite my skepticism, the team from ConsulCube presented well. They displayed a grasp of Accenture’s charge to them and stayed on topic. The following illustration about Accenture was done well:



The actual presentation was done well, but I have to disagree with some of the points illustrated. I agree with the consultants that COBIT is not the right path for our company, however, I disagree that our current path is cutting edge and doesn't need upgrading. 

To explain my reasoning let's back track a little to about COBIT.

COBIT 5 is the latest edition of ISACA’s globally accepted framework, providing an end-to-end business view of the governance of enterprise IT that reflects the central role of information and technology in creating value for enterprises. The principles, practices, analytical tools and models found in COBIT 5 embody thought leadership and guidance from business, IT and governance experts around the world.

Sourced From:
http://www.isaca.org/COBIT/Pages/default.aspx?cid=1003566&Appeal=PR

I agree with the consultants that COBIT 5 is cumbersome and complex. Their illustration of one process alone captures that essence.



However, to be fair and to avoid being influenced on a singular decision, I felt that some additional investigated was warranted. Furthermore, with some additional  there has been some unfavorable trends based on economic research. According to Shengnan Zhang and Hans Le Fever in the
Journal of Economics, Business and Management, Vol. 1, No. 4, November 2013 COBIT is on a decline.

The following is an excerpt from the article highlighting the point:

Some researchers [3] have 
pointed out that the biggest disadvantage with COBIT is that 
it requires a great deal of knowledge to understand its 
framework before it could be applied as a tool to support IT 
governance. It is reported [4] that the usage of COBIT 
decreased from 14% in 2008 to 12.9% in 2010. This trend 
proves the conclusion that COBIT is not as easily 
implemented as originally estimated [5]. ITIL and ISO 
17799/ISO 27000 are the two most frequently used 
frameworks. Many executives agree that even though they 
believe COBIT is a good framework, they prefer to focus on 
ITIL and ISO27000. 

http://www.joebm.com/papers/84-M021.pdf


To circle back to my disagreement, I want to point out that as a large mulit-national organization of consultants were are faced with the pressure of divergent agendas. We can maintain a distribution point, but without a centralized mandate it can get increasingly difficult to enforce our numerous consulting teams across the globe to carry out our desires. Various applications and platforms are used in this industry. Consultants, by nature, tend to be more inclined to use their own out of the box preferences rather than managements. In part, this is what makes them successful but it is also difficulty we face as managing a company of consultants.

Our current mandate should be to find a centralized platform that can mitigate the potential divergences as well as bring a unity to the company that can enhance our consulting capabilities.

Regards,

AJ Varghese





Saturday, March 1, 2014

Zara Case Prep and Reflection

Zara: IT For Fast Fashion

Preparation:

Location - La Coruna
Zara is Inditex's largest chain of stores. Zara was founded by Amancio Ortega.

Case background: Xan Salgado Badas and Bruno Sanchez Ocampo are discussing Zara's Point of Sale system. The debate essentially is "if it ain't broke why fix it".

Current POS system runs on DOS. The software works fine but the technology is behind the times. Microsoft doesn't support DOS anymore. A major risk is that the hardware vendor for the terminals would upgrade their machines so that they are not DOS compatible anymore. The vendor has indicated that they wouldn't change but they would not give that indication in contract form so it is not trustworthy.

Business Model: Speed and Decision Making



Marketing - Zara spent little on Ads but it did spend heavily on its stores. Stores were always located in a city's prime retail district. Layouts were changed every four to five years. Individual stores didn't have the freedom to set garment prices.

Zara did not try to produce "classics" clothes that would always be in style. The clothes were designed to have a short life span.

Zara introduced substantially new design collections at the start of the fall/winter and spring/summer periods. In contrast to competitors, new items were continuously brought out. Approximately 11,000 new items were brought out, while competitors averaged 2,000 to 4,000

Finance and Operations:



Distribution Centers - relied a great deal on automation and computerization.

Stores - heavily relied on PDA's. PDA's used primarily for ordering, handling garment returns to the DC, and transmitting information from headquarters to all stores.



Debate:



Reflection:

The direction of Zara's IT has been a difficult debate these last few years. Still maintaining DOS systems has been a topic of concern that has bothered me for a while now. As a debate, however, the issues seemed to need further investigation. This required the need to seek out consultants who were not influenced by internal agenda's. When the Info Consulting Group arrived for presentation, I was a bit skeptical about what research might have been conducted. However, despite initial skepticism, I was impressed with the consultants presentation.

The consultants grasped our business objectives and included them as vital points in consideration. They even broke down the points into specific categories of key decision making. The categories being Speed, Future and Growth, Low Cost, Decentralized Decision Making, and Stability and Reliability.

Operational flow was well illustrated with the following:



Ultimately, the consultants suggested that at this time there isn't a need for changing the POS system. Initially, at the end of the presentation I was inclined to agree with the consultants that the company should continue our path and not upgrade the POS system. Since the systems still worked and we are making money, I could see the opportunity of investing in growth via expansion over IT infrastructure.

After some reflection, however, I have to say that I am not convinced and need to disagree with the consultants and would prefer to upgrade. It is true that our current systems still work, but our single greatest objective should be to maximize shareholder wealth now and in the long term. While we are still functional and profitable, I believe that the increased value in a successful implementation of a good POS system would lead to greater profits. Obviously, there would be an initial investment required, but we will eventually face that challenge anyway. To clarify, eventually all our technology will at some point in time need to be upgraded. It is just a matter of when.

 For some more in depth detail of the data further, we can look at some supply chain commentary. The following is regarding the bullwhip effect. The bullwhip effect in this case being defined as, unforeseen spikes in demand or over-estimations of demand stimulate the supply end of the chain to respond with changes in production. Production and supply issues then impact the consumer end of the supply chain and the effects ripple up and down the chain.

"The first step in minimizing the bullwhip effect is to understand what drives customer demand planning and inventory consumption. Lack of demand visibility can be addressed by providing all key players in the supply chain with access to point of sale (POS) data. Suppliers and customers must then work collaboratively to improve both the quality and frequency of information communication throughout the supply chain. They may also choose to share information through an arrangement such as vendor-managed inventory (VMI). Eliminating practices that introduce spikes in demand, such as order batching, can also help. The higher order cost associated with smaller or more frequent orders can be offset with Electronic Data Interchange (EDI) and computer aided ordering (CAO).


Pricing strategies and policies can also help reduce the bullwhip effect. Eliminating incentives that cause customers to delay orders, such as volume transportation discounts, and addressing the causes of order cancellations or reductions can help create smoother ordering patterns. Offering products at stable and fair prices can prevent buying surges triggered by temporary promotional discounts. Special purchase contracts can be implemented to encourage ordering at regular intervals to better synchronize delivery and purchase."

http://www.usanfranonline.com/managing-the-bullwhip-effect-on-your-supply-chain/

I want to note that this is not to say that we have an issue currently with the bullwhip effect, but rather that it can be used as a stressor to indicate that technology can help mitigate certain potential issues.

To conclude, I want to recommend that we upgrade our point of sale system. The discussion warrants further investigation into which specific system to upgrade towards but it should be done. My proposal is to have the consultants re-align their research with the intent of upgrading.