1) Stakeholder Management: Attain clear support from the executive stakeholders from the beginning of the project and schedule regular check-in meetings with them ahead of time as they tend to be very busy and are often pulled in many directions. Set the tone that their participation is needed and that they will need to approve change requests which is not uncommon. You should also use clever people skills and empathetic listening skills as you interview the many high-level stakeholders in the early part of the project so as to diffuse conflict and get consensus on disagreements about scope, business goals, order, and to find out who will be the thorn in your back as the sooner you know that the better. Also, accept that stakeholders will be different and they may not even directly work for your company which is ok as those ones tend to offer specialized expertise and are often very creative.
2) Communications Management: It’s common to have one or two stakeholders who are difficult, protesting the project through their actions, or who are otherwise egotistical, and/or just plain difficult to deal with. As a project manager, project consultant, or business analyst, it is your responsibility to deal with these people and situations. One way to do this is to understand the communication styles of all project stakeholders early on in the project and document this. Strength Finders, DISC, and many other communication style tests can help with this or you could consult a person who has a lot of international travel experience – they are often helpful understanding group communication dynamics. You should also know when to be direct, indirect, and/or silent in your communications. Communication is mostly about listening and perception and as project manager you are not the direct boss of the project team members so your ability to drive tasks is heavily based on your communication and motivational skills – so ask all team members what you can do to clear their roads either yourself or in partnership with other stakeholders. This reduces surprise road blocks down the road and encourages silent people to speak up.
3) Quality Management: Having worked on many complex projects in highly regulated industries over the last 5 years I have noticed a shift towards agile methodologies vs. waterfall. From my perspective this is really about quality and timely flexibility. Aligning the project tasks in small pieces allows you to test the results independently and faster, and if the results are bad that’s a good thing because it’s just one piece of the project and you can learn from it – getting an early warning. Yet to get better quality out of an error you need to have documented what went into the error from beginning to end and you need intelligent consensus. On SDLC projects there will be many small errors which then raise questions about other systems and how they relate to the business rules. Yet with good process flows, screen shots, and JAD sessions with key people, you can ensure that these errors are nothing more than normal bumps in the road. Every project has its bumps but the real test is having above average quality on budget and on time at the projects end thus creating a reusable plan others can learn and be inspired from.
4) Risk Management: In this new era where almost everything is in the cloud and hackers are targeting large and mid-sized companies to steal and sell their data, every risk analysis document/plan should take into consideration data security, customer privacy, access controls from the project team, and there should be an independent audit plan – often out of scope of the project and done by a different group for checks and balances. No project has no data so data is always a part of a project, sometimes more and sometimes less. Question number one is who should have access to the data and at what point? In today’s environment you should embrace a need to know policy and you should document that to reduce risks. You should also imagine a worst case scenario and be prepared for it and run this by the executive project sponsors, and/or risk officer if your company has one.
Another common risk is project delay. Have you analyzed how a one or two month delay would affect your critical path and logical task order? For some projects it may not matter and for others it may cost your project millions more. It may harm another dept. or a related project thus in your project risk document you should list the longest delay your project could handle and the dependencies of that delay. Delays on projects, especially SDLC projects, do happen and are not necessarily bad and they can be dealt with but your project team needs to be ready for it and the sooner they know the better.
If you want to hire me to speak at your next event or consult for your company on these and related topics concerning project risk, process improvement, project management, and related areas please contact me.