Tuesday, October 23, 2007

Don't react too late in the project

As a project manager, you must plan a lot of things.  Even if you have a methodology which you follow, you must plan how your team will follow it, especially if most of you are not familiar with it.  You have to be aware of the quirks of the methodology and how it will affect your work, as well as your team's efforts and schedule.

Take for example the Information Engineering Methodology where you have different phases in the project and the first part is the Initial Information Architecture.  How detailed must the output of that activity be?  Should you have the main modules only, the first level only?  Which at the lowest level, would give the function hierarchy diagram up to the first or second level, which would be the functions and sub-functions, mainly.  The initial ERD would probably only have the core entities and relationships and as such, you would have the function vs. organization matrix  and not the process vs. organization matrix.

After that, there is an assessment of information needs and as such, and details of the processes involved within each function could be detailed there.  When that happens, you are at least build up something slowly.  Then the other details you gather could be used for the final information architecture deliverable.

Sometimes though things don't always go as planned especially when it comes to things that cause delay.  It could be users with whom BAs must speak with. Or it could be the number of holidays that occurred.  In any case, you must also account for things you learn from the various phases and activities that you have with the users from the client's side.  An example of which is how you could present an activity to the users.  If you have a number of users, sometimes one contrarian could affect the others' opinions.  So if you carefully think about your strategy, you could win over them contrarians.  A sample activity that you could have trouble dealing with such people is when you have a worksheet that you would like them to fill up so that it could help your team assess the data.  If your team has given their thoughts on how to make the worksheet, it is important that you review it before you even show it to the users on the client's side.  If possible you could already gather inputs from the other members of the project steering committee.  As project manager, you are the one who has the voice that these other people will be able to hear.  Your team would be doing a whole lot of things involving the preparation of the activities but you are the one who's always meeting with the project steering committee.  If your team already started gathering information using that worksheet and turns out that it is something that the project steering committee approves of, your team would end up doubling their efforts in order to revise their work.  It would end up as something frustrating for everyone and would probably cause delay too.

Another example. If your team has been asking for access to resource people from the client's side, take action.  You could ask the members of the project steering committee for their commitment in the project.  Having a steady group of people who act as resources from the client's side would lessen the confusion. Really.  But if you don't see that immediately, there could be a lot of communication issues and inconsistency issues.  That's why as a project manager, you have to step in immediately when you notice these things.

A project is something that both your team and the client must work for in order to achieve it.  Project managers could be crucial to the process.  That's why it's important to learn from experience.

No comments:

Labels

Blog Archive

Connect