IT Staff Convention 2007:Project Management Maintaining Control and Keeping on Track

From Provider Wiki

Project Management: Maintaining Control and Keeping on Track

IT STAFF CONVENTION 2007 – April 27, 2007

Moderator: Alec Lamon, Wharton

Notes: Gayle Belford, ISC

How has the definition of project management changed?

• Meaningful communication throughout the project is key to it success.
• It is very important that the project product reflect the business process.
• Ask the user how their business currently runs versus how they ultimately want it to run. This should help the users think strategically.
• Requirements change over the course of the project (i.e., scope creep).
• The delivery date should be realistic; specifications should be re-evaluated at specific milestones.
• Manage client expectations by making changes throughout the project. Try to get users to agree on what will be in each progressive version of the product. It is okay to define the ultimate “blue sky” for the project, however, in order to get all requirements on the table.
• To manage user expectations, give users constant feedback and carefully listen to them.
• It is helpful to give users an initial mock-up of the project.
• Recognize and help users to recognize the differences in developing an application from scratch vs. implementing a canned or existing application.
• To help deal with difficult clients with decision-making power, point out that if the ultimate product is unsuccessful or breaks, it could be an embarrassment. In other words, be honest about consequences, rather than sugar coat.
• Try to get the user to make an investment and assume responsibility in the project in an attempt to mitigate unreasonable user requests.
• Explain time and money constraints in implementing additional client requests.
• Try to elicit buy-in from the user.
• Keep a list of current projects so the client can see what is in the works, as well as what’s in the queue already.
• Keep user abreast of project status at all times.
• Explain the concept of competing priorities and lack of resources. Make users understand time, money, effort involved.
• Ask client to identify a single point of contact as a liaison.
• Be aware that projects tend never to close. For this reason, it is important to define exactly who the ultimate owner of the project is. At some point, user should take ownership of project.
• Recognize that users sometimes think they know what they want initially but later change their minds.
• Ensure client contacts communicate to constituents exactly what will occur with the project. Client decision-makers are not necessary final end-users.
• If necessary, shadow ultimate end-users to track how they do things.
• Training can help mitigate the gap between perfect and imperfect systems.
• It is helpful to get end-users involved early on in the project.
• Clearly identify types and variety of potential users early on.
• With any external vendors, ensure they know the client’s expectations. Ideally, they should also be a part of the project team.
• Include a statement of work in the contract with the vendor. Try to partner with the vendor.
• Try to get any agree-upon terms with the vendor incorporated into actual written contract.
• Use both the “carrot and the stick”; vendors can capitalize on Penn’s name. Be clear about your expectations with vendors regarding the unique needs of the academic community (e.g., importance of timing).
• Once the project is completed, conduct a wrap-up meeting with the vendors involved to determine what worked and what did not.
• For the project life cycle, suggest that all vendors post any communications to one common spot, rather than use emails that all may not see.

Is project management an art or a science?

• Such instruments as Gantt charts and MS Project could be considered the science end of project management.
• Perhaps human relationships forge are the art part of project management.
• The team should always have a project postmortem to determine what went right, what went wrong.
• It is possible to learn by “getting burned” on a project.
• The project manager should recognize who prefers doing developing vs. who prefers the communicating end of the project. Ideally, each team member should try work on both skills. To this end, people should try to better manage themselves.
• Better developers learn the importance of communicating. They recognize that better communications can mover the developer into the management ranks and more money.
• It is also important, however to recognize and manage the “geek factor” (i.e., some individuals prefer developing to communicating).
• Sometimes, face-to-face communication is best in getting results. Emails are not always the ideal form of communication.