Seems like we've given up a lot of privacy concerns and identify theft concerns as well in the name of immediate feedback and realtime response. HIPAA (The Health Insurance Portability and Accountability Act of 1996) even seems to be less of a concern in order to easily get yours and your kids health records fast online including blood test results and ultrasounds etc.

​Security is an obvious concern and we are really exposing our vulnerable side in the name of easier online access, sharing and collaboration. AI can probably help with that, but I wonder how far out we are from real nice tight security, plus still easy and real time sharing of important and needed data. And hackers will likely still be always one step ahead of us anyway if they really want it.

... Is not going to save your project. There, now that I have your attention, let's talk software and projects. What do you use for your project software? One tool? Many tools? Open source? Home grown? Free? Expensive? Site license? Per user license? Small learning curve? Large learning curve? Desktop? Cloud-based? The options are almost endless. And now hundreds of players stand where just a couple stood 20 years ago. Can one of these save your project? Probably not. Let's discuss...


Project software these days comes from a lot of companies who are certain their offering is going to fix your project, task, resource, or financial management issues. Sometimes they have built it to solve their own scheduling and PM needs and feel they have now perfected it and it's ready to push to the waiting PM public. I've worked with some of these organizations. I've talked to the individuals behind the software and supporting it. Usually great people. And passionate. I've reviewed and overviewed their software. And sometimes it just happens that their emails start to bounce because sales just weren't happening or their product didn't really solve anyone else's needs like it did their own.


But who knows... it may work just perfectly for you. I believe that they all solve a need. PPM... task management... budgeting... resource planning... issue management... risk tracking... bug tracking. Does one software solve all needs? I haven't found one yet. Can you make it through a project without any of these? Yes, I believe so and I have. I wouldn't recommend it on large projects – at least use a scheduling... task management/progress tool. But yes, you can get by on one project or smaller projects without any real tools if there happens to be nothing available in your organization.


What do you really need to focus on?


If you have no specific software or your are bare bonesing it through a project on a wing and a prayer, what do you need to manage to get through? What should you focus most or all of your attention on? Because it isn't about what you do – it's about doing what you need to do to succeed and even excel but not go overboard, right? So, it's more about the best practices that are top priority. Let's consider those...


Managing tasks. The bottom line is this - you have to track the tasks. That is – right along with good communication – at the heart of every project no matter what shape, size, dollar amount, timeframe or industry it is in. You have to track the tasks and task progress and to do that just on paper would likely make the project essentially non-manageable. This may be the only project management task that I would say you could not just do on paper. It would make managing the team and their assigned tasks very difficult. You could use a spreadsheet, but that's still a tool.


Status reporting. Reporting status on the project is key to ongoing communication and keeping all team members, all stakeholders and the customer on the same page at all times. Any word processor will do, but if you're considering that a tool then you're resorting to email (I'm not taking that away from anyone in 2018) and that's ok too...and gives you easy revision, resending and tracking.




Managing the budget. Another tough task without any tool at all – I like to go basic and use a spreadsheet so I almost never budget within a specific project management focused tool. How about you – what do you use to track, manage, forecast and analyze project financials? I like my homegrown spreadsheet that has built in formulas and has been re-worked over time to do exactly and track exactly what I want and what my project customers and senior management have wanted over time. I'm open to change, but not really.


Communication. Communication is Job One – in my opinion – for the project manager and business analyst. It is at the bottom of success on every single project I've ever been a part of. If it goes poorly, so does the project and vice versa. But you can handle communication through phone calls, emails, and meetings if you need to. Just don't forget to listen – that's half of excellent communication.


Managing resources. Again, one of those tasks that I like to do with a spreadsheet. It's part of the project schedule in the tool, but for me only in so much as I ensure that project resources aren't overloaded on a project at any given time. Beyond that, forecasting who I need and for how long... I build that together with my above referenced awesome project financials forecasting and analysis spreadsheet. They go hand in hand on most projects and why is that? Because your human resource is usually your most valuable and expensive piece of the project puzzle.


Issues/and risks. Go with a list here. If you have no real issue or risk management (and I know they aren't the same thing) tool, then a list will suffice. I often end up just using an Excel or similar spreadsheet for this anyway... nothing in a specific PM focused tool. The key, of course, is to keep all issues on the radar, know who is working on each and what the status of each is. If it's a big enough issue, it's going to need a task on the revised project schedule anyway.


Summary / call for input


So, the best damn project management software available isn't going to save you or your project. It may make things easier, but until robots and artificial intelligence completely take over, it's up to us to make the difference between success and failure on the project – not the tool or tools.


Thoughts – do you agree with me and this list? You don't have to, but I'd love to hear feedback from you if you feel differently. Thanks!

Is that cutting edge Cybersecurity technology making your CSO drool and ready to pay boo coos of internal dollars on a bleeding edge tech project to showcase at the next user conference or Black Hat digital security convention? Is that latest platform recently available to showcase your web apps on recently available and ready for you to use?


Making a project come to life because of the technology that an executive wants to try or wants to say that his division is using is a bad reason to have a project. And I feel it goes against some sort of unwritten code of ethics for project managers but I will get to that in another article, most likely (these ideas have to come from somewhere).


Here's my take... never ever ever ever make the project about the technology. It can be awesome. And it can be disastrous. You can end up being in the latest tech magazine and your stock may soar. Or you may end up on the heaping pile of Ryan Leaf NFL busts in terms of tech failures. You may find that bust lands you with a headline on CNN about a tech startup losing a billion dollars on a failed project to implement a new security solution that ended up in security breeches, identity theft and lawsuits because your tech team wasn't quite ready to handle such a project. But then again, they say “there is no such thing as bad publicity” - there is always tomorrow to fix it or capitalize on it. Unless of course this bad decision put you out of business. Then there is no tomorrow.


So what do you do when it appears that the customer or your senior management wants to jump in head first because of the technology? For me, it comes down to these three things...


The end does not justify the means. Getting there isn't really half the battle. Getting there successfully with the right solution is the whole battle – the whole project. There is no half battle or partial project. It's all or nothing. It's not about the right process or the coolest technology or the headlines... good or bad. It's about the successful solution. I had one organization I was leading a project for where the client company was so excited about our solution we were implementing – the first of it's kind in their industry – that they went ahead and published go-live dates in a major industry publication under assumptions made with and by the account manager in our organization who sold them the project.


Unfortunately, those dates became the hard and fast - or “drop dead” - deliverable and implementation dates that I had to build my project schedule backwards from in order to complete and meet the deadlines. There were no other options and no option for me to put together the realistic schedule that I knew and my team knew we could meet safely and accurately. What happened? My team and I found ourselves working onsite at the customer location for two weeks just before Christmas working through issues to get to go-live on time. Blew through money (beyond budget) faster than Usain Bolt can run 100 meters, but we made it!


The desired technology may not be right. The obvious problem is that the desired technology – this bleeding edge choice for the solution – may not be the right technology. The project team needs to understand business processes, what the “as is” environment is and what the desired “to be” environment should look like and figure out if the customer's perception of the project is the true need or if the project is bigger (or smaller) and the customer request or need is merely a symptom of the real project. Then, and only then, can the project team step back and formulate the real project. Following that, they can – with the customer's input – identify what a technical solution should look like including what the proper technology to implement really is. Still hopefully a cool one, but it may not be what the customer is hoping for. “Backing into” the solution from the technology is the wrong way to go... it's like reading English from right to left... pretty painful... bad outcome... headaches.


The skill set may not be there. Finally, the team may not have the skill set to implement the desired technology. That doesn't mean it can't be done. But it probably can't be done without a change order to get the right resource or resources onboard – at least temporarily and probably expensively – for this specific project. Don't get me wrong, implementing a bleeding edge technology in any industry for the first time is feather in the cap of the delivery organization as well as a gem on the resume of the project manager, the business analyst and the entire project technical team. Win-win-win. And the customer organization comes out looking great, too. So if they want it, and it's the right technology for the project team and the customer is willing to pay for it – or your organization can see the benefits of the end publicity – then go for it. The return on investment (ROI) for all involved to eat some costs will be high.


Summary / call for input


The project is the project. That's what the team needs to focus on. It's like putting blinders on because sometimes the customer or senior management will interject their needs and desires and those may be in direct contrast to what is best for them and for the project – and they don't realize it. Stay focused on the successful end solution while taking all these suggestions along the way, but resist the urge to act upon them. At least not until you've ensured that they are the best roadmap to success.


Readers – have you had customer project scenario where it was all about the technology and the success of a new solution? How did you calm the enthusiasm while you sorted through the need to determine if that was the best path for the project. You can just proceed with the customer request as is, but if you get to the end and implement something that doesn't really solve the need, the onus is on the delivery team, not the customer.

I hate to call anyone a jerk. There's no getting around it... rude says one thing, but jerk sort of says it all while still keeping your language and integrity intact. You deal with someone who has less consideration for mankind than you do every so often, I'm sure. Both in your personal life and in your professional life. It's unfortunate, but it's life. And how you deal with it – or them – says a lot about you and keeping your responses and actions / reactions controlled can mean the difference between success and failure.


I had a fun moment on date night with my wife last week. I dropped her off in front of her favorite women’s clothing store in Downtown Summerlin in Las Vegas and began my mission of searching for an impossible to find parking spot to show off my awesome parallel parking skills. After losing out on four other spots that I noticed and tried not to run over texting shoppers to get to I finally located one and it was mine. Mine! Then the aggressive jerk behind me pulled as close to me as possible and waited trying to discourage me from backing into the spot. He didn’t know who he was dealing with. I waited, he waited. I put it in reverse and even backed up just enough so he noticed. He didn’t move. So I waited some more. He waited some more. Every vehicle behind him understood and left. Yet he stayed. I still had my reverse lights on. I even honked my horn a couple of times and politely waved him around. Still he stayed. Finally after about 5 minutes he got upset enough that he speed around me as fast as he could nearly clipping my vehicle in the process. Victorious, I took the parallel spot I had earned. Won actually. Yay for me.


Ok, in terms of project management I'm not talking about parking spots or road rage, and not really the team either, though that can be the case at times. It has been for me on my team a couple of times and with colleagues in the PM infrastructure a couple of times. I will get to those types of situations here as well. But it can be outsiders – maybe more like “extended relatives” in the PM world like stakeholders, senior management, customer team members, etc. Unfortunately, this probbly comes up more for business analysts than project managers considering the wide range of positions and individuals they must deal with and work with on a daily basis.


Now that I've established the population and genres that I'm about attack... let's do this. Here are some of the jerky situations I've found myself in, or colleagues have, or you may so I'm hoping to help here a bit... read on...


The figure head customer project manager. Have you ever had a project customer who placed a “project manager” on their side and it seemed like his only job was to be your watch dog? I have – really just on one major technical implementation. He never really contributed anything to the project – he just mimicked what I did, relayed what I said and emailed me a lot to check progress. The progress information was readily available to him in the weekly status I was producing and sending, the project schedule updates I was providing and the daily email updates I was sending out to all key stakeholders. So at the end of the day he cost the project a lot on the customer's side of the equation while apparently adding no value. He was often rude and sarcastic even though the project was going well but I knew it was in my best interest to move forward, not complain, and continue to provide him and the rest of the stakeholders with the same high quality and – often daily - updated status information I was already providing. The key is to stay in control, and control how you respond and interact.


The PM colleague who has advice for everyone – a.k.a, a better way of doing things. Have you ever had one of those colleagues who seems to know a better way of doing things and needs to interject that into nearly every conversation you have with them? I did once. It's almost amusing but it is certainly annoying. Especially when you really don't need the advice but it is somehow validating to them. The best response, stay heads down working and respond kindly. I'm never big on creating workplace drama – I like to avoid the drama as much as possible which is probably why I work so well remotely and managing virtual teams. I like the camaraderie with team and colleagues, but I can do that through email and Skype and video conferences just as well if it cuts out the 10-20% time lost to individuals who are focused on the negatives or other things that are not productive to my work, my team and my projects. I'm certainly not anti-people, but I am certainly anti- gossip, busy work, complaining and time-wasting. Avoid these people when possible, and politely keep working while they show up to vent or interject to you in your office. Stay in control of yourself and your actions – that is always the best route to take.


The customer who wants everything for free. I actually had this one happen just two weeks ago... again. It happens periodically on projects and in consulting engagements. Everyone wants free publicity and freebies or free project add-on work without thoughts that maybe your company will incur expenses getting this done for them or that maybe you even have kids to feed – like in my case. The client contacted me outright, not the other way around. I quickly drew up a proposal for him in the middle of the night because this was an international potential client and I wanted to respond quickly since he was likely near the end of his company's work day and seemed anxious to move forward. He quickly replied that he wanted the free version. I wasn't sure what he meant by “free version” but I replied, “great, you can have this work free with these other 'x' services.” His response? “No, I just want the free version.” I explained that either way it takes time and effort on my part. He still wanted the free version so I had to cut him loose even though I was still offering him a great value for what he really wanted. But I could not give it away. Sometimes you just have to walk away when they don't get it. Your time is worth more and you lose money giving too much time to those potential project clients who just don't understand the value. They probably never will. Cut your losses and walk away... unfortunately that's what I had to do.


Summary / call for input


Again, I consider myself a fairly nice guy and I'm very flexible and easy to work with unless you are A) Endangering my family in any way, B)Trying to mess with my project, or C) Trying to take my parking spot that is rightly mine (apparently after this current experience). Just be fair and others will be fair to you... usually. Sort of the golden rule, you know?


Readers, what is your take on this list? Do you agree? What jerks have you had to deal with and how did you handle the situation? Please share and discuss.

Does your organization handle large, complex technical projects? Do you have diversely skilled project teams assigned to those projects? How about overloaded project managers? Are they juggling several projects at once? This sounds like every organization I've managed projects in and every company that I've consulted for along the way. If this is your organization, too, then you likely need the best of the best in terms of a business analyst on each project being led and executed on for the project customers your organization is serving.


If you do need the “best of the best”, then what skills or characteristics are you looking for? What defines the best for your organization's project needs? While BAs are not project managers, the most successful BAs manage the entire business analysis effort. This means that the BA is proactive and dependency-aware. It also means they manage themselves well, the stay on track with respect to commitments and deadlines and can handle task delegation, decision making and issue management as needed on the project.


I've thought about the overall skill set and characteristics needed to pull this role off efficiently and productively and coupled it with my experience leading projects, working in combined project manager and business analyst roles I've come up with my list of ten characteristics of an awesome business analyst. As you are reading through these, please be thinking of your own personal experiences and comment with your additions to this list...


Great customer interface. The great business analyst is a critical liaison between the project manager and the technical team. This person is often the driving force behind the accurate, complete and detailed documentation of the final project requirements. Why? Because the organizational to tech cross-over ability and skills that many project managers will lack must be handled in this role. And they help the tech lead interpret those functional design ideas into technical design specifications for the design and development work on complex technical solutions.


Subject matter expert. The skilled business analyst is vital in his project team role as a subject matter expert. This helps him to work with the client to document accurate business processes that are then used to create detailed, complete, and accurate project requirements. The business analyst's technical knowledge coupled with his understanding of the design process and the likely end solution makes him an invaluable resource for the project manager the project team and the project client.


Good technical cross over. The very valuable business analyst has a diverse amount of technical knowledge. Not necessarily tech lead or developer knowledge, though that is a plus, but rather a very good technical acumen that gels with the project management-type organizational skills and knowledge he also likely possesses.


Can project manage it when needed. The indispensable business analyst can and often does act in the role of project manager both when the project manager may be tied up on another project and also when interfacing with the team and client and a decision needs to be made on the project's behalf and the project manager isn't currently available.


Critical attention to detail. Detailed oriented focus is needed by the business analyst on the project for a variety of reasons: to assist the project manager and fill in there as needed, to work closely with the customer sponsor and team and the project team to define and document requirements, and to help track and resolve issues throughout the engagement.


Skilled communicator. I've often said that communication is Job One for the project manager. However, communication skills are possibly the most important characteristic of the awesome business analyst if for no other reason than the vast responsibilities this position has on the project and with the team and customer. Miscommunication can lead to so many problems on the project and this role ends up interfacing with all stakeholders...making accurate and thorough communication necessary.


Facilitation skills. The business analyst is going to be required to facilitate many meetings and sessions during the project such as periodically leading the team meetings and formal project status meetings for the project manager and then requirements meetings with the customer as well as design sessions with the technical project team.


Experienced critical thinker. Business analysts are responsible for evaluating multiple options before helping a team settle on a solution. While discovering the problem to be solved, business analysts must listen to stakeholder needs but also critically consider those needs and ask probing questions until the real need is surfaced and understood. This is what makes critical thinking and evaluation skills important for the business analyst on the project.


Skilled with PM and organizational tools. The business analyst needs to have a good command of the use of various project management related tools such as project scheduling software, basic tools like Word, Excel and PowerPoint, and others that might be needed such as task management software, bug tracking software, risk management software, file management software, and even modeling tools like Visio, etc.


Conflict resolution. From time to time conflicts can arise. I'm not talking about fisticuffs...at least I hope not. But disagreements among technical team members or with members of the customer's staff can arise. The skilled BA will recognize this quickly and work with both sides to come to a mutual agreement. Patience is also a virtue...because any conflict resolution requires patience and understanding. And good listening skills.


Summary / call for input


The business analyst isn't necessarily the leader on the project, but his role may be the most diverse and sometimes the most critically necessary for project success. The project manager will serve as the overall communicator and decision maker on the project, but the business analyst will likely have an even closer customer facing role than the project manager...meaning this position may be the most valuable in helping ensure customer satisfaction and completeness and acceptance of project work performed by the project team.


How about our readers? If you're a business analyst, what do you think about this list? What would you add to or remove from this list? What are your top 3 or top 5 characteristics for a valuable business analyst? Some organizations – often smaller organizations – may only hire a project manager or business analyst to handle both roles. Have you worked with such an organization and did you find it to be successful?

You know how the old saying goes. “The customer is always right!” How many times have you heard that expressed over and over again by a disgruntled customer or friend who feels they received less than a fair deal from some vendor? Now think about that in terms of a project engagement where tens of thousands of dollars and possibly even millions of dollars are at stake. How do you think that paying customer feels about service and being told they’re not always right?


Usually the customer either comes with a set of detailed requirements or you must extract those requirements from them. Either way, they definitely come with a problem that has necessitated the project you are about to embark on with them. But are they right? And should you point out that they aren’t if you’re concerned they’re going down the wrong path. The answer is yes, definitely. Here’s why…


They may be chasing a symptom, not the real problem


When the customer comes to you with the need, no matter how certain they may be of that need, it is still your job to ask questions. Discuss the need with the project sponsor. Meet with the end users to identify what they feel the issue or need is. The real need may be deeper – the customer may only be coming to you with a symptom of the real problem. If you don’t tell the customer they are wrong and solve their real need, you may be only putting a band-aid on the real problem and when that becomes evident, you’ll have a very frustrated and dissatisfied customer on your hands.


They may be selecting the wrong technology


Many times someone at the customer organization – possibly even the project sponsor – comes forward with a project and they are certain that a particular ‘latest technology’ is the perfect solution for them. This is usually the result of something they’ve been told or have read about. Indeed, that technology may truly be what is needed, but it is still the delivery team’s responsibility to dive into the detailed requirements for the project and verify that the technology the customer is requesting is really the best way to solve the problem. Often times when the customer has pre-selected the technology for the solution, it is not the best technology to use and a red flag should be raised.


They may be asking for add-ons they don’t need


On the delivery side, we always want to avoid ‘gold-platting’ the solution. When we gold-plate, we deliver add-ons that aren’t part of the requirements and they end up costing us on the delivery side and putting the project budget in danger.


What we’re talking about here, though, is the other side of the coin. The customer can be asking for add-on services or functionality as part of the solution that they don’t really need. Indeed, the solution delivered ‘as is’ may meet their needs – such as providing a needed report through the basic implementation making it unnecessary for them to pay additional fees to have custom reports developed. It’s our duty on the delivery side to identify those situations, alert the customer and work to keep the customer costs as low as possible.


Summary


The bottom line is that you as the project manager and your skilled project team are the real experts. That’s why you’re being hired to work the project and deliver a solution. The customer may have come into the engagement thinking they needed ‘x’ and you’re telling them they need ‘y’. But it’s your job to tell them that and to deliver an end solution that meets their needs…whether it’s a cheaper solution than they anticipated or a more expensive one. Then let them decide with you on how best to proceed.

How is PM success defined? What skill set or character traits do I need to become a good project manager? Ever individual who is considering entering the field should ask this question of themselves, their colleagues, and some PM experts. The field isn’t easy and it definitely isn’t for everyone.


As I’ve managed and succeeded and failed my way through about 20 years of IT project management, I’ve made mental – if not always written – notes of what works and what doesn’t and what qualities in a person seem necessary in order to succeed in this career. And while I’ve worked on this list more than once and it’s not the same every time, I can say that what I consider to be key personal traits or characteristics of a good project manager generally boil down to these four qualities. There are definitely more – and I’m open to your arguments, thoughts, and suggestions, but here’s my list…


Communicator. This is the top one for me. In my opinion being an efficient and effective communicator is the number one role the project manager must play. If you can’t communicate well with your project team, your project customer, and your senior management, then you shouldn’t be in this business. You’re going to get weeded out early or eaten alive during your first project kickoff meeting. During one requirements meeting I had a business analyst who was reduced to tears because that person was taking everything personally and not communicating requirements and expectations well or controlling the room. A good BA because of the combo of technical and business skills, but not project manager material. I’m still trying to block that project from my mind.


Negotiator. Issues arise on every project. I think every project I’ve ever run required scope changes and change orders. Negotiation is just part of the PM game. It always will be. So a good project manager must be ready to leverage business practices, technical knowledge, project status, and customer needs to keep the project headed in the right direction. It may require different resources, more money, a phased approach…whatever it takes it will almost always require some give and take…some negotiation. This is a key skill that must be there.


Confident leader. The project manager must exude confidence. I don’t mean an ego trip. But they must be a confident leader. I usually have a bunch of very talented technical people on my project team and they all have big egos. It helps to be technical when leading those resources…no doubt about that. But you must also be confident, take charge, and lead them. Otherwise your team will go over your head with the customer, with your management, etc. to get things done. You must lead them.


Stubborn. This may seem odd, but it is important. It is broad. You must be a good decision maker. But it goes beyond that. You must also be stubborn. Stick to your decisions. Why? Because everyone from the customer paying for the implementation down to the developer building it will question you along the way. If you’re weak and not stubborn, you could end up changing your mind many times and the end result will be a project thrown off track by an indecisive leader who isn’t long for this career path.​

Project management certification. Is it helpful? Does it get you jobs? Does it increase your project management skills? Does it add value to you as a project manager? Does it add value to the organization you work for? Monetarily...is it worth it? Should hiring organizations require it? Should hiring managers demand it?


These are all great questions and the answer to most is probably...”it depends.” It depends on the person, the company, the project management office (PMO), the sector and/or industry you work in, the customer's needs and preferences, and sometimes even the amount of work that the hiring company wants to put in to hiring the best project managers around.


Let's consider a few factors...


The job posting. I've long upheld that – at least in my opinion – only the most lazy hiring organizations or human resources departments actually demand project management certification. Yes, some projects and market niches really require it. For example, some public sector positions may require it to meet certain quotas or standards. And some organizations doing business in those sectors may need to require it in order to secure contracts in that sector. That's very understandable. But if that is not the case, then I think the organizations that outright require it are using lazy hiring practices and likely missing some of the very best project management candidates available for every one of those “certification required” PM jobs. In my opinion, go with experience first, and then take certification as a nice add-on if it comes with the candidate. I've built great teams with that philosophy.


Is it value added? Yes. I believe, without a doubt, that any certification in a field you are dedicated to adds some value to you as a candidate. And, therefore, it would add value to the organization that hires you as a project manager because to is a certification to the profession. I'm not stating that it makes you a better project manager – I haven't gotten to that point yet – but it is still a certification in your chosen field so yes, in my opinion, it adds value. To you and to the organization.


Does it make you a better project manager? I'm going to go out on a limb here and say “no.” I realize that any knowledge – any positive knowledge, at least - usually makes you better. But in terms of a better project manager, more organized, more ready to lead your team and project and customer to project success? I'm going to say overall...no. I think an argument could go either way on this so I know I'm going to catch some flack for this stance.


Monetarily...is it worth it? I think to truly answer this question we would need to pose it to the newer project managers who have the minimum hours of experience and are gaining project management certifications. We need them to answer here...is it helping you find your first big project management gig? Is it helping you increase your salary and move up in the organization? My answer – in general here...and especially since it isn't that costly – would be yes. But keeping up with the training and the PDUs can be an issue. Still, I would answer this one personally with a yes.


Summary / call for input


I'd really like to hear feedback from project managers – new ones, old ones, certified ones, non-certified ones, employed ones, and those looking for new or next project management jobs. What's your take on this? Is project management certification – most notably PMP (project management professional) certification from the Project Management Institute (PMI) or any similar certifications – worth it today? And, the next question is, which is best? Which should you get first? Let's hear responses and discuss.

Managing a project is hard enough. Managing all the changes that can and often do happen on a project makes everything that much harder. It's like trying to hit a moving target or trying to ride a bull through the streets of Mexico!


Here's the simple definition of change...To make the form, nature, content, future course, etc., of something different from what it is or from what it would be if left alone. Most of us don't handle change all that well. In our personal lives or our professional lives. I used to be one of the least flexible people you’d ever meet. I liked taking the same vacations because everything was familiar. Boring. But confidence and a willingness to try new things changed that for me.


Are you good at handling change? Do you readily accept and embrace change? Do you run away from change? Are you somewhere in between those two ends of the spectrum concerning change? How you handle change may say a lot about you and your type of leadership…and it even may say a lot about your ability to lead projects effectively – or at least how much conscious effort you’re going to have to put into each and every turn and bump in the road.


The way I see it, the project manager must always be open to change. Certainly, they must be stubborn leaders…steadfast in the decisions they make, stern in the delegation of tasks and enforcement of deadlines, and not afraid to call the customer out if they aren’t delivering information, task progress, or decisions on their end. Indeed, the project manager must be bold in all aspects, but change is inevitable and they must be open to change.


Why? Because…


Customers almost always change requirements and priorities sometime during the project. Customers probably present the most frustrating changes. What they want changes. What they need changes. Their organization changes and suddenly you’re working with a new sponsor or your project takes on a higher or lower priority. So many customer changes can affect you and your project. Be prepared and try not to pull your hair out.


Your project resources may requiring changing during an engagement. This won’t happen on every project, but it can happen on any project. It can be frustrating when it happens on the customer side. And it can cause significant project impact when it happens on the delivery side of the project – usually because some other project absolutely had to have the specific individual resource that was on your team. Stay calm, make appropriate plans to strategically onboard new project team members when necessary and always do your best to present it in a positive light to your project customer. The last thing you want to do is cause the customer to be overly concerned about any project resource changes that must be made.


Issues and risks will come up. Remember those risks you were dutifully planning for early on in the project? A few of those will likely actually come to light…and you’ll need to react to them to either avoid their impact or to mitigate their impact. The key is to be ready, have a plan in place, and make sure that you did that early risk and issue planning. It’s actually important that it does happen so that you can always be proactive and remain in control.


Organizational changes can and do affect the projects that we manage. Lastly, things will happen in our own organizations that will affect our projects from time to time. Priorities may change, personnel may change (one of our resources might be let go or might leave for another opportunity at another organization)…it’s impossible to predict. And it’s really impossible to prepare for these types of changes. They key is to know they can happen and to not let them overwhelm you and cause you to react negatively and possibly take any actions that may be detrimental to the health of your project or projects.


Summary / call for input


Most changes that we have to manage as project leaders throughout the life cycle of our projects have nothing to do with anything we initiated...we just have to jump on the bull and hope to steer it down the street successfully. No project goes through the cycle without experiencing some change...we just need to be ready for it and prepared to handle it calmly and responsibly...with the help of our team and stakeholders.


How about our readers? What other areas of change affect projects? Do you have certain strategies of dealing with project change that you can share?