Key Variables to Remember When Planning Projects
No surprises, no variables, nothing changes during the life of a project, right?
Sure. Raise your hands if you’ve ever managed a project that hasn’t experienced at least one change order / scope change. No hands? Didn’t think so. I know I haven’t had one and that isn’t a indication of poorly performed requirements definition efforts or poor scope management. It’s a case of long projects fleshing out slightly more complex or detailed requirements along the way and the delivery team ==> customer team relationship evolves and the delivery team’s (and customer team’s) understanding of the business processes and needs in play and the “as is” vs. the “to be” environment becomes clearer.
So what varies from project to project that can affect the project, the planning, the schedule, the budget, the requirements, the templates… maybe even the methodology and how you manage the project. After all, projects are never really cookie cutter projects, you need to look at each one uniquely anyway, right?
The customer.
Obviously, the physical customer varies from project to project – although you may end up running several projects over a period of time for the same, satisfied customer… and that’s aways a good thing. They only come back if they’re happy – and have budget for it. And with the varying customer comes varying needs, varying wants, varying neediness, varying wishes, varying awareness of their own business processes and requirements, and varying understanding of technology and the necessary solution. Some customers will participate as if they are part of the delivery team and some may disappear for most of the engagement because they either don’t have the time to be involved or don’t have the inclination to be part of the actual project work and progress.
The money.
Certainly the money varies with each project engagement. Every project has it’s own budget and, likewise, every client has an amount of money available that they are willing to spend on your services. My favorite client is the one who understands the value of the offering and isn’t trying to get the cheapest deal or project proposal possible. You can make yourself the cheapest option when you are trying to land a project and bring a client onboard, but that doesn’t make you the best and may actually weaken your ability to deliver on the project. Funding for the project may be so low that the project won’t be a high priority for the organization, making resources and time devoted to the project hard to come by and therefore your ability as the business analyst hard to deliver on. That’s a lose-lose.
Likewise, you don’t want to be trying to overcharge a client either – give them a reasonable and accurate price. Then wait.. and listen. Don’t negotiate to a lower price if it will mean you lose money unless landing this particular project customer is truly worth such a scenario. Be ready to say “yes”, “no”, or “let’s talk” depending on how bad you want this project and how flexible you can be. It’s always ok to say “no” and walk away.
The team.
Your project team is going to vary from project to project. In a matrix organization, you’re going to work with some team members over and over again, but the overall makeup of the team will likely never be exactly the same again – depending on how large your organization is. So, it’s a given that the talents, emotions, collaboration, cohesiveness, and accountability will vary somewhat from project to project and team to team. And just because you have 90% of the same team back from a very successful project for the next project… don’t assume that the new 10% will just fall in line and be just as successful and collaborative, and team oriented and cohesive. They may actually become combative and cause other team members to be less productive, efficient and cooperative as well. You’ve heard the phrase “One bad apple can spoil the whole bunch.” That can also be true of the project team. So the good business analyst needs to be able to recognize team chemistry and never take for granted or assume that team members that worked well together before will be able to replicate that – even if there are no new team members. Be ready to deal with conflict and confront team resource issues head on.
Key assumptions.
Documenting, clarifying and revising assumptions before the project, during kickoff and throughout the full engagement is critical to success. And assumptions are going to vary from project to project. In fact, as the experienced business analyst on the project, you are likely going to be in the best position to document key assumptions for most projects as you have both a technical understanding and a project management strategy and delivery understanding of the project as a whole. Assumptions on a technical project are not just technical in nature, but also involve vendors, risks, and even input and actions of the customer and supervisors. The project manager, customer team and tech team will also be key managers of assumptions throughout the engagement.
Outside vendors.
Outside vendors on any project can present a wildcard type of affect – and the vendors as well as their level of affect and impact on any given project will vary from project to project. The database supplier on a pharmacy or medical project – with all of the related HIPA issues and drug / prescription information is very different than the database supplier on tools and car parts information. The variance can be great from project to project and from industry to industry.
Risks.
Finally… those risks. Several risks are going to be a given on every project and should probably be hard-coded on to your project risk registry as you begin the risk identification and management process. But many of the detailed risks are going to depend on the vendors used, the technology used, the requirements of the project, the customer’s environment, and the project team… just to name a few. The business analyst and the project manager – actually all stakeholders – need to play a part in that risk identification process and the overall risk management process… it’s too important not to do it right and dedicate the proper time and effort and dollars to the management of those varying risks.
Summary / call for feedback
I realize this is just the tip of the iceberg in terms of what varies from project to project as no two projects are exactly the same. But I think this is a good start on some of the big ones and more obvious ones that will vary no matter what the project is or what the industry is.