Payson Hall is a consulting project manager for Catalysis Group, Inc. in Sacramento, California. Payson consults on project management issues and teaches project management. Email Payson at [email protected]. Follow him on twitter at @paysonhall.
In a new project, there are always going to be challenges and delays, and when the end date is looming, you may be tempted to rush through the contracting and procurement process. But that can have dire consequences down the line if roles, responsibilities, and expectations aren't clear. Take the time to communicate.
If you have to replace a complex existing data system in production, decisions about when and whether to go live should be treated with gravity and care. One process that can help keep you honest is developing checklists that describe very clearly what is expected to be accomplished and verified at each milestone.
Much time has been spent examining the project manager’s role in IT project success, but the role and duties of project sponsors are often overlooked—even though sponsors are an essential element of success (and failure). Here are ten rights and obligations a project sponsor should perform to improve project success.
The first step in any significant software procurement is to assure there is a clear definition of the business problem being solved. If you don’t know what you want, you aren’t prepared to negotiate for it, so you'll end up with a system or tool that isn't what you need—and you'll likely be disappointed at delivery.
Negotiation occurs on a spectrum, and different tactics apply in different situations. For instance, you’d treat a one-time transaction differently from an ongoing client relationship you want to nurture. Have you developed effective negotiating skills? Are you applying negotiating skills appropriate for the context?
Some project managers have little experience bringing a project in for a landing, so they can be dismayed or just blindsided by organizational change needs and stakeholders’ expectations at delivery. Here is a checklist of some commonly forgotten items to address when a project goes live, so be sure to plan for them.
There are people who will use "being agile" to justify software engineering practices that could be perceived as lazy or even bad. The specifications are going to change, they say, so it would be a waste to engineer more to begin with than the minimum viable product. What's expediency and what's just poor practice?