Thursday, October 30, 2008

Review of a Project Management Tool - Change Management

After reading some blogs about Project Management and some reviews of Project Management books, I realized that a common topic was Leadership & Change Management.

Researching in those topics I found a Harvard Business Review article about change management that talks about the common mistakes that companies make in projects.

Here is a summary of those Common Mistakes:

The first common mistake is to not establish a sense of urgency. A lot of times management do not understand how change initiatives or new projects can drive employees out of their comfort zones. They just want to start the new project without considering the effects on the employees. If people are not motivated, the change initiative will go nowhere. Management has to establish a sense of urgency to start and to get good results out of a project. One way can be to present unpleasant facts, like competition gaining advantage over the market. Management has “to make the status quo seem more dangerous than launching into the unknown” (Kotter, 1995).

The second common mistake is not forming a good and powerful team to lead the change effort. First of all, if management is not fully compromised to the project, the change initiative will fail. Management has to be an active supporter and employees need to know it.

A third big mistake is not creating a vision about the new project or change initiative. The leaders of the change initiative have to create a good vision of the project that can be communicated throughout the whole company. That again can be a big problem, if there is a vision, and the employees that will be affected by the change do not know it, and do not know the importance of it, the project will be hard to implement. And most importantly “communication comes in both words and deeds, and the latter are often the most powerful form” (Kotter, 1995

Another mistake is not removing obstacles to achieve the new vision. Management has to think about the obstacles that are going to appear in the process of trying to achieve the new vision. They have to think carefully about all the aspects that can arise, and they have to put themselves in the employee’s shoes to find out the probable problems.

Another big error is not planning for and creating short-term wins. Short term wins foster the motivation of employees. Management has to find out ways to make employees feel that the project is advancing and that results are being achieved.

The last big mistake is not to anchorage changes into corporate culture. “In the final analysis, change sticks when it becomes “the way we do things around here”” (Kotter, 1995).

Reference

Kotter, John. Leading Change. Why Transformation Efforts Fail. (1995) Harvard
Business Review OnPoint, 1-10.

Wednesday, October 29, 2008

Project Failure - Migration of T-Star

Project Background
T-Star was a back-office software system for Asset Management Companies (AMC) operating in Japan. Around 80% of AMC in Japan subscribed to T-Star for their daily operations. This project was an application migration project and was outsourced to an IT services provider in India. The estimated project cost for T-Star’s owner was 14 million USD.



Project Scope
This system was to be re-engineered on Java technologies. It was developed using COBOL and had 1.5 millions lines of code. This project was divided into 4 phases (System Analysis, Design, Development and Testing). The total duration of the project was around two years. The team size remained around 35-45 persons including three project managers.



End Result
The project ran for twelve months and was scarped after the end of the analysis phase. All project managers employed by the IT vendor resigned. The vendor also lost market reputation. This resulted into an adverse impact on its Japanese projects.



Key Mistakes (From Vendor Side)
Project Approach
Feedbacks provided by customer on use cases and business requirements on many instances was informal, verbal or were on hard copies. This resulted in confusions and a lot of time was wasted in tracking and managing feedbacks. The methodology selected was object oriented and iterative in nature but it ended up in standard SDLC customized model.
Customer Management
An active customer engagement starting from Sr. management level up to team level was desired. Relationship should have been managed more effectively from onsite (Japan) with dedicated account manager/onsite coordinator from the start of the engagement.
Resource Management
Resources with required skill set were not found on time resulting in poor quality of work. Many crucial resources e.g. Test Lead, SQA expert etc. could not be inducted in time which affected customer’s confidence. Some key resources including project managers left the project midway.
Culture and Language
This project like any other Japanese projects needed managers with prior Japanese project experience. Communication was a big issue as all customer communication was in Japanese. Team members faced language barriers.



Lessons we can learn from this project failure
Before start of any project- deliverables, risks, format of delivery and assumptions need to be clearly defined & communicated to all stakeholders. Set reasonable customer expectations in terms of what would be delivered, how frequently and on what quality levels. Always report issues and problems to the customer, those faced by the team due to lack of clarity in requirements, frameworks or any customer specified items (this was most often ignored!). Further, closure of above issues should be tied up with project schedule and quality of deliverable. Always ensure that enough time is budgeted for internal as well as customer reviews. Take customer feedbacks on time or else inform the customer the impact on schedule & cost due to late feedbacks. Document each and every customer feedback and do not rely on verbal or informal feedback. Set up a dedicated project management office to monitor, track and resolve critical project issues.

Tuesday, October 28, 2008

It may not be textbook, but it's working so far...

so, i've recently completed a project which has been working quite well for our company... i'm not sure it can be considered textbook management and implementation of a project, but it seems to be working so far... any advice on how i could have done things differently/better, or what i should be looking out for in the weeks to come would be appreciated... i call it "enhancing the export order management process at company xx"

************

As the Manager for Production Planning and Delivery Execution for a company involved in offshore export, I was recently assigned the task of improving the Export Order Management Process at my company. Like many other companies, our company has over the years narrowed our business focus to our core competencies, and as such, outsource our export logistics to a broker, who manages our export shipments. This means that activities such as booking vessel space for containers, negotiating freight rates and managing relationships with carriers are handled by the broker.
The main challenge with this seemingly straight-forward business process was that our company runs SAP, while our small broker outfit operates on a simple query database within which all key order information is stored. With our broker having better access to real time information, the order management process used to rely on manual query downloads into a spreadsheet generated by one of the broker’s employees throughout the week, from which our company’s export order management and delivery execution was carried out.
The biggest issue with executing on “snapshot” query downloads was that the moment the query was downloaded into a spreadsheet, the data was outdated. That is, because the order management was affected by many variables such as changes in the ship’s schedule, production upsets, and customer changes, there was a need for “real time” data for both our employees and the broker to work off of.
The project was simple in concept: map the current process, identify data inputs (both source and people), determine critical data and who should be inputting the data into a “real time” environment. The real time environ from our perspective needed to be SAP, as this was our single “truth”, and we needed the broker and all other relevant parties to work off of SAP.
When the preceding was completed, I worked closely with an IT Business Architect, who took my business needs, worked with the end users to design the solution, and then went to work with IT Technical for the technical programming.
After 4 weeks of designing and programming, we moved on to a week of testing to create all possible scenarios imaginable and the solution passed the test. Our company now has all key export order management and delivery execution data in SAP, and SAP can at the clock of a button generate real time reports for all key personnel involved in export order management.

Saturday, October 18, 2008

Welcome

Welcome to IT Project Management blog. You will find a list of interesting topics about information technology project management in this blog.