|
Long time since my last post here. Well, there are a couple of reasons for that. I'm now taking German lessons and also studying application automation technologies to solve some issues regarding to the company's new E.R.P. software. On my spare time (not much, by the way) I'm playing with my little baby daughter (joyful and truly relieving time, indeed :o).
Nevertheless, I found some time to write and I would like to share some thoughts about "predicting project implementation problems". I think there is a huge difference between predicting problems and creating them. A Project Manager must be prepared to foresee things. Nothing supernatural implied here, it's all about experience. Regarding to project management, a brief look into the past can tell you a lot about the future. But that, I hope, you already know.
I've recently faced some complicated issues with a couple of fire starters in the E.R.P implementation team. The discussions they started at the team weekly meetings about the "problems" they were "foreseeing" were causing nothing but confusion and time loss. The real problem, in my case, is that they do not report directly to me, so I had to workaround to correct the undesired behavior.
In my opinion a problem (in a project) is an issue for which you have no known solution yet. Otherwise it's just a "task" you must accomplish by applying some known technique. The funny thing here is: the problems they brought to the meeting table were not related to their own tasks. They were concerned about things being developed by the IT department, a.k.a. my playground. They even suggested to ask the board for an extension to the project's deadline based on the doubts they had about the feasibility of the tools we had presented to solve major issues regarding to the integration of our current systems to the new ones.
I don't know of a single product on the market that can be applied at any company, even the smallest one, without some kind of customization. In our case, we have a set of reservation rules for our hotels that is really apart from the market standards. That is a core feature of our business and everyone at the company knows that. We, from the IT department, know that in depth, because we maintain the software and support all the users working with the current reservation systems.
I know that our proposal for the systems integration was bold. It is based on unusual tools and programming techniques (which I'm not going to discuss here). The fact is: we were sure about the solution when we proposed it. I, as a Project Manager, would never adopt a solution which "may" work. That is not acceptable.
Cutting a long story short, we accepted to postpone the project's deadline, but not because we had doubts about what we were doing. It was because we could sense the need the other half o the team had. They wanted to see things working before they could believe. We were dealing with a trust issue, and that is serious matter.
Despite of the fact that we had never failed a single delivery to them, they were sure we would not be capable of performing our tasks in time. On our side, we kept all the original deadlines, and I'm sure we can actually deliver everything under our responsibility before the schedule (as usual). This was the way - documented in the meetings' minutes - I found to show them that they were wrong. So, here comes a little piece of advice: if you don't know how to do something, it does not mean it is impossible. It just mean you have some homework to do.
|
