Deep learning will radically change aspects of our medical care. How well do we need to understand how AI tools work?

In clinics around the world, a type of artificial intelligence called deep learning is starting to supplement or replace humans in common tasks such as analyzing medical images. Already, at Massachusetts General Hospital in Boston, “every one of the 50,000 screening mammograms we do every year is processed through our deep learning model, and that information is provided to the radiologist,” says Constance Lehman, chief of the hospital’s breast imaging division.

​In deep learning, a subset of a type of artificial intelligence called machine learning, computer models essentially teach themselves to make predictions from large sets of data. The raw power of the technology has improved dramatically in recent years, and it’s now used in everything from medical diagnostics to online shopping to autonomous vehicles...

Often times at the heart of a successful project management practice is a project management office, or PMO, that has been structured to create a path of success for company projects and the project managers who lead them. Sounds like a good plan, right?


The problem is that while more than 50% of all projects fail to some degree, one survey of project managers showed that 58% feel that their organization’s PMO is or has been ineffective at serving the needs of the projects and project managers within the organization.


47% of survey respondents indicated that their company’s senior leadership had little to no visible involvement in the project management office and 41% offered no training to project managers.


Finally, 66% indicated that there were either no repeatable processes or templates in place for project managers to use, or that the practice was definitely lacking and change needed to happen in order to be successful.


I have personally seen project management offices created, dismantled, and re-created again only to fail again all within the same organization within a timeframe of less than two years. PMOs come and go and left in the aftermath are frustrated project managers who thought they had an organization that was backing them and that they could call their own. Also left behind are customers of these organizations looking for consistent and successful delivery of project solutions only to find that chaos often ensued and good, solid repeatable practices were sorely lacking. Without repeatable practices and templates in place that have proven to bring success, we’re often leaving our project successes to chance and luck…and that’s no way to build a solid project management practice, is it?


There are generally three different types of project management offices: supportive, controlling, and directive. For the purpose of this article, I’m referring to the directive type of PMO that takes over projects by providing the project management experience and resources to run the engagements. That’s the type of PMO I’ve worked in before and the one I personally feel is the best structure for the company when it’s done right.


From my experience, there are five key ingredients to a successful PMO. There are no guarantees of success, of course, but if these five ingredients are present, the chance of your project management office achieving long-term success is greatly increased. These five ingredients are:

• Executive leadership support
  
• The existence of repeatable processes
  
• Hiring the right people
  
• Strong, dedicated PMO leadership
  
• Meaningful capture of project knowledge and data
  

Let’s examine each of these in more detail…


Executive leadership support


I’ve seen many PMOs come and go and one thing is for sure… first and foremost, a project management office must have buy-in from senior leadership within the organization in order to survive. Why? You would think good processes would be first. Or even just having the right people. No, if your CEO on down doesn’t support the PMO, then it’s in trouble from the beginning. One recent survey showed that for 26% of PMs the #1 frustration they cited was a lack of management support.


When company leadership doesn’t buy-in to the PMO, here’s what can and often will happen. The good projects will go to other departments in the organization – handpicked people who the CEO or other senior leadership ‘trusts’ with their babies. Funding won’t go to the PMO, it will go to other departments and processes that leadership deems worthy or more impactful to the bottom line of the organization. This is often a very misguided thought process based on a lack of understanding of how much successful customer projects can mean to an organization financially and in terms of reputation. Good people and leaders will be moved to other departments because they are needed elsewhere and should not be ‘wasting’ their talents running projects. And finally, the organization – as a whole – will not adopt the PM processes or see value in the PMO’s existence because, well, the CEO doesn’t back it so why then should they?


The existence of repeatable processes


Another key ingredient for PMO success is the creation of and existence of repeatable PM processes, procedures, and templates. In order to try to avoid the ‘50% of projects fail’ scenario, it’s important to have processes and templates that work and that your project managers can continually go back to for each project that they manage. If a good, proven methodology is not in place for managers to use that will help them repeat their successes, then you’re just leaving project success to chance or luck and that’s a certain ingredient for eventual PMO failure. Without the proper tools in place for the project managers in the PMO, projects will continue to flounder on a regular basis and the structure of the PMO will become meaningless in the organization.


Hiring the right people


It’s not enough to just staff the PMO with project managers who have their project management professional (PMP) certification. PMP certification can help ensure that everyone is on the same page with language, but it is no guarantee of experience or success. Likewise, having in-house people move into project management roles ensures they have some connections as well as knowledge of the corporate structure and goals, but it is still no substitute for experience. To do it right, you need a blend of experience, strong resource management, some financial management knowledge, and the right amount of entrepreneurial drive in your fleet of project managers. Because these individuals need to be able to think on their feet and make decisions when there’s no one around to help them do that. And they must be able to not wilt under pressure because the target will be on their head throughout each engagement that they manage. And if the projects are in an IT environment, it is essential – in terms of credibility, estimating, leadership, and decision-making, that the project managers have a technical background. Not really hands-on technical, but they need to be relevant from a technology standpoint.


Strong, dedicated PMO leadership


Too many times the PMO Director ends up being a project manager who just happens to be leading the project management office. That’s really a bad call unless your organization and PMO is very small. The director needs to be a well-connected leader in the organization. One who can knock down obstacles for the project managers on their projects. Someone who is an experienced resource manager with an interest in mentoring project managers and helping them map out a career path that is beneficial both to the company and the resource. This should actually be someone with some direct resource staff management experience, not necessarily the most experienced project manager in the organization. The PMO Director is not someone who should be overloaded with five or six of their own projects. It’s understandable that a leader like this may be in high demand for a very visible project or to assist a PM on a troubled project with a high profile client, but that needs to be the exception, not the rule.


Capture of meaningful project knowledge and data


Finally, the project management office must have processes in place to capture knowledge and data that will help project managers learn from mistakes and repeat successes. Lessons learned sessions can be a great way to review the project with the customer and project team, discuss what went right and what went wrong, and understand how to run better projects in the future. And best of all, the information that comes out of these sessions can be made available to all project managers in the PMO so that lessons will not have to be learned over and over again.


The problem is that - when the project is over - the team often quickly moves on to other tasks and projects and never gets around to conducting this very vital and useful step in the project process. In fact, 63% of respondents in a recent survey indicated that end-of-project lessons learned sessions were conducted either never or for less than 25% of the time.


By skipping these knowledge gathering sessions and failing to capture data and issues from the project we are managing that can be helpful to us and to others in the project management office, we’re potentially setting ourselves up to repeat the same failures. Or worse, to miss out on repeating the same successes. Save documents and lessons learned from past projects in a common location where project managers can collaborate and share what worked and what didn’t. We learn a lot from what went right or wrong for us, but we’ll learn even more from what went right or wrong from ten or twenty other project managers. Don’t miss that opportunity to share and aid in each other’s successes. That is what helps build great project management offices.


Summary


These five ingredients that I’ve discussed are certainly not the only characteristics of strong PMOs. There are many factors that can go into making a project management office succeed or fail and some are always going to be dependent on the type of company they are in as well as the PM professionals that make up the PMO. These five, however, are critical and when practiced they will definitely help get your project management office on the right track toward success.

In an age when project failure rates sadly top 50%, having the chance to actually restart a project that has been stalled, canceled or put on hold for whatever reason, can be a very positive thing. But it is definitely not with out great challenges. Often, the project manager asked to restart the engagement is not the same one that ended its previous iteration. It is worth noting here before we go any further that restarts - like 2nd marriages - are just as likely, if not more likely, to fail than the original engagement.  


Considering project failures or work stoppages, they usually happen for one (or more) of three key reasons. These are:


Personnel issues


On a halted project that does get the chance to restart at some future point, usually 70-80% of the original personnel has changed since the last work stoppage, if not an entire personnel overhaul. Finding internal information on where the project stood may take some searching and definitely some due diligence on the part of the project manager and project team. At the very least, the project manager and key project team members are looking at a period of interviewing internal personnel prior to ever re-engaging the customer for discussion and project re-start activities.


Funding issues


Another key reason projects come to a screeching halt is often because funding has run dry. I personally led a project for a very well known government institution that had stopped one year previous. I then took over as the project manager with an entirely new team and even a new customer sponsor. With restart came new requirements and the data integration needs had changed, but the funding available had not. It wasn’t long before funding became and issue – and like my statement above about restarts often ending in failure – the project not surprisingly came to another point of work stoppage. Project budgets need extreme oversight and cannot be taken too lightly. Never assume that the customer has more money to spend or will come up with it just because they’ve already spent ‘x’ amount of money on the engagement. They may pull the plug due to funding issues at any time during the project.


Requirements issues


The third main reason why projects often get put on hold is due to changes or disagreements in requirements. It may be that the delivery team and the customer are unable to agree on and finalize requirements. It may be an issue solely within the customer organization – meaning changes at the customer’s site or with their end user needs may be turning requirements into a moving target. That type of situation obviously makes it impossible to move forward on the project without expecting to deliver a useless end solution. That scenario is something that neither side wants to see happen – thus making a work stoppage a much more viable solution at the present.


Steps to restart


It’s no small undertaking to restart one of these stalled projects. The project manager may tend to think that he and his team have nothing to lose since they can’t do any worse than the first team. Actually, nothing could be farther from the truth. This isn’t a scenario where you’re coming in as the Superman project manager trying to rescue a project that is in progress but is currently failing. I’ve been there – usually experiencing success and recognition, but not always.


No, taking over a stalled project that has been on the shelf for weeks, months, or more than a year is different. You often lack the type of up-to-date information that you would have if you were taking over a failing, but in-progress, project. You sometimes have very limited access to the previous project personnel. And your customer personnel may even be very different. However, they are still skeptical, all eyes are still on you and your team, the target is still on the project manager’s head, and expectations from senior management are high because they’ve likely gone through significant work to convince the customer to put the time, money, and effort into restarting the previously failed engagement. It’s one shot and you have to make it work. No pressure…right!


The restart process is basically a five-step process of trying to get your team, your information, and your customer in perfect alignment to resume work at a productive and efficient level. Let’s examine these five steps in detail….


Step 1 – Get knowledge transfer from the account manager


The first step to a successful project restart must start where the project likely originated – with the account manager or sales person that closed the deal with the customer. At this point, the project manager and team need to treat it almost like a new project and get the sales to delivery knowledge transfer and customer information that would likely happen with a new engagement. Learn the customer quirks, assumptions, preferences, and concerns from the person who met with them when everything was fresh, new and the project outlook was bright. Get the original sales materials, the draft project schedule, the original resource plan, key assumptions, report mockups, etc. – anything and everything that was mapped out as part of the sales process with this client.


Step 2 – Connect with the previous project team


Once you’ve managed to get all attainable information from the original sales person or team, it’s time to meet with whoever remains from the original project team. In this step, you’re looking for more of the same information as Step 1, but with the twist on what happened during the engagement to get the project to the point of work stoppage. Be careful, because there will likely be some damaged egos and frustrated project personnel who are wondering why they aren’t getting a second shot at this project (assuming they are still employed by the delivery organization).


In this step, it’s critical that your team acquire the historical documentation for the project. You’re looking for weekly status reports, any deliverables that were presented to the customer, notes from project status meetings, budget iterations, and as many iterations of the detailed project schedule as you can acquire as you try to piece together what activities were going on and how things were changing on the project.


Step 3 – Look at the failure points


Using information from the account manager and the original project team, piece the details together and examine what seem to be the project failure points. If it was a requirements disconnect, look at the status reports, iterations of the project schedule, and notes from the planning sessions to try to determine where things went wrong. If it was funding, look at the many iterations of the resource planning and budget status reports – assuming they are available (and they should be as part of the database of project status reports if you’re involved with a functional and organized PMO). If it was a personnel failure in your own delivery organization, you may not get the objective information you want from the first project team. That may have to come from the PMO director or – more likely – from the customer who you’ll talk to in the next step.


Step 4 – Engage the client


It may seem like placing the first actual discussion with the client in Step 4 is rather late in the process, but while there’s much fact finding involved in Steps 1 through 3, they really shouldn’t take that long. You’ll want to be working fast to get back on track with the customer because they have likely been built up with lots of hopes and dreams from your own senior management regarding the upcoming project restart. They are ready, willing and excited about talking to your new team – though it is likely that they are also carrying a decent amount of skepticism with them heading into this second iteration of the project. They’re going to be holding you to high standards and will be quick to pull the plug again if things are not going well in the early stages of the project restart. We’re assuming here that the problem was not likely internal with the customer – because if it were we would probably not be at a point of restarting the project.


Conduct a formal discussion with the client. But the first thing on the agenda must be a thorough listening session. You and your team have just spent the first three steps fact finding on your own. You must be careful not to go into this Step 4 telling the customer how it is. After listening to the client and understanding their perception of how the project was proceeding and why the work stoppage happened, then – and only then – do you begin to discuss what you’ve learned and the ideas you have about what went wrong and how to avoid those issues this time around.


Step 5 – Rework and rollout the project schedule and budget


As a progression of Step 4, we transition into Step 5 and actually work hand-in-hand with the customer to rework the project schedule for all remaining work, plan out the resources needed, and discuss the remaining project budget in detail. Of course, you and your project team have already done this internally and come into this customer discussion with the draft work already done and a starting point (or shall I say, re-starting point) for all three of these items. Look at this as a re-kickoff meeting of sorts where expectations are re-set, assumptions are once again documented, agreements are made with regards to deliverables, milestone dates, and project task responsibilities.


Summary


A carefully planned project restart – that begins by following these five steps – can be a successful undertaking. Nevertheless, it’s very important that you take nothing for granted. No matter how friendly the renewed relationship with the customer is, it has been strained in the past so leave nothing to chance. It’s important at the actual project work restart point following the kickoff (or re-kickoff) that you obtain a formal customer signoff on the many discussions and agreements you made during the project kickoff session. Don’t make one move toward actually restarting work on the project until the customer acknowledges in some written form that they are in agreement with your new project team on the project direction, schedule, statement of remaining work, and the planned outcome.

​For this article I would like to discuss what I consider ten of the most common mistakes that project managers make or allow on their projects. These are in no particular order – they are all important and all can lead to extreme budget overruns, failed schedules and frustrated project clients. Basically, they can all lead to project failure. My top ten are:

Failure to ask enough questions to get clear enough direction before starting the project (also known as: Taking the customer’s need at face value without digging deeper)

Our project clients come to us with problems. Big problems. And they are almost always certain that they know their need and they may even be telling us how to solve it including what technology to use. Sounds easy, right? The problem is, we’re the project experts and it’s our job to ask questions – the right questions – to uncover the real need of the client. What they are presenting as the problem may only be a symptom of what really needs to be addressed. It’s the responsibility of the project manager and team to ask the tough questions to get to the real requirements and the real problem. Then, and only then, can we understand the need, price the effort and map out a solution. If we act on the customer’s initial concerns without digging deeper we may end up solving the wrong problem and spending a lot of the customer’s project dollars on a solution that won’t work for them.

​Involving too many people in key decision-making activities due to lack of confidence and experience

It’s ok – even wise – to seek out the advice of colleagues, peers, senior management, and more experienced project professionals who may have already encountered issues similar to what you’re facing. Project managers who lack experience with a given situation should do this – especially if the project has reached a critical point and needs quick action. However, more is not always better. Involving too many ‘subject matter experts’ in a decision process can lead to a significant delay in the actual making of the decision, meaning you may miss the boat on responding to the issue or at least cause the project to suffer severe damage in the process.

Not communicating openly enough with the project customer

The project manager who thinks they are ‘protecting the customer’ by keeping things from them runs the extreme risk of alienating the customer or worse – causing the customer to loose all trust, faith, and confidence in the integrity and ability of the project manager and team. I like to work on the assumption that the customer will always find out. I always do with my kids. My parents always did with me. My wife always does. It’s just that way. Sooner or later you’re going to have to give the customer the bad news so do it quickly and get them on your side as you work to correct the problem situation. Never go it alone. Only keep it from them long enough – if you keep it from them at all – to think up some possible courses of action to present to them…and that better be quick.

Putting too much trust in the self-management of the project team

No one likes to be micro-managed. But allowing your very talented and egocentric team too much leeway can cause your project to veer off course. Give them an inch and they’ll take a mile. Seriously…these are skilled individuals who already don’t like to be told what to do – especially by someone less technical then they are. Assign them their tasks and hold them accountable for them and keep abreast of what they are doing by communicating frequently with them. You must assume that if you haven’t heard from a project team member in awhile that they might be working on some tasks that are slightly to significantly off course. And with that extra effort there goes your project budget. Stay on top and keep them focused.

Micro-managing the project team

I already said that no one likes to be micro-managed. And sometimes new project managers will feel that they have to do that. A skilled project team with big egos will resent this behavior immediately and make life miserable for the new project manager. For the experienced project manager they may become confrontational or passive aggressive. At any rate, their behavior may become detrimental to the rest of the team and the progress of the project. Allow them the proper freedom to do their job. They’re experts. Recognize that and treat and trust them accordingly.

Relying too heavily on senior management direction

You need senior management. And they need you. But they have their own jobs to do. Make them interested in your project and have them at the ready if you need them to knock down barriers your project may encounter. Do this by sending them weekly status reports and schedule updates. But that’s just informing them and that’s a good thing. The flipside is being far too needy and running to them with every issue and decision that needs to be made. Your project will suffer from your lack of decision ownership and your career will suffer greatly when you show your senior leadership that you’re really not a leader at all. At least not a very confident one.

Failure to carefully manage project scope

Project scope is like the lid on a shopvac. Leave it on and it successfully manages all the dust and grime in the shopvac. Take it off while it’s running and chaos and a significant mess ensues…and you get to clean it up. The project manager and team must be in control of the project scope throughout the engagement. If it looks like it might be out of scope, something has to happen. The work or issue must be assessed and a change order must be presented. If scope isn’t managed and change orders aren’t created then the project budget and timeline will take repeated beatings throughout the engagement and the end result will be a project that is either canceled or deployed way over budget and way off schedule.

Failure to continually monitor the budget

I make it a habit to check the project forecast every week as I update the project budget with actuals that I get from accounting. By doing this I know I’m never far off budget. A 10% budget overrun is far easier to fix as you discover it than a 50% budget overrun is to fix three months later when it rears its ugly head. And it’s much easier to break the news to the customer or your senior management that the project is going to come in 10% over budget – assuming you can’t fix the overrun – than it is to tell your CFO that a $1 million project is coming in $500,000 over budget. Ouch.

Signoff on requirements that are not detailed enough

I always say that requirements are the lifeblood of the project. Documenting requirements is never easy and getting good, detailed requirements from the project customer that mean something to the delivery team who will be creating the solution is a very difficult task. What the customer considers good and what your solution architects consider good are usually two very entirely different things. The experienced project manager anticipates this gap and plans for enough time in the schedule to sit down with the customer and hammer out real requirements…no matter how much the customer contends that they already have done that on their own. They haven’t. At least I’ve never seen it in 20 years of managing IT projects so far.

Don’t plan enough planning time – Plans the project schedule too tightly

Being overly optimistic with the project schedule and task durations is never a wise move. It’s noble to say, “We’re going to get this done in two weeks instead of the usual three weeks.” But it’s also stupid. If there’s an extreme crunch, that’s one thing – and even then you need to let whoever is putting the thumbscrews on you that the date is not likely to be met. But if you’re just trying to look good…don’t do it. I’m not saying you should ever pad. I’ve been a developer and I know how much estimates can get padded anyway…that’s why I’m glad I was once a developer and I’m still and excellent technical estimator. Don’t pad, but be real. Your project needs a good leader, not a superhero who thinks he can accomplish the impossible.

It hopefully doesn't happen that often, but every now and then we get into a creative project argument with other stakeholders who may feel passionate about a decision, key piece of information or a path to the proper project solution. After all, creativity is personal, and creative thought processes can often collide... with loud results. We feel passionate as project managers and creative directors – and creative team members - about all of these things, so it's easy to understand that there may be someone else on the other side of the table who feels different... but just as passionate...

The concept Project integration management is a key skill that is the tightly woven into the PM industry standard processes laid out by the Project Management Institute (PMI). As defined by PMI, project integration management are the processes and activities needed to integrate the various elements of project management, which are identified, defined, combined, unified, and coordinated within the Project Management Process Groups.

Within the project management body of knowledge (PMBOK) guide, project management processes are presented as discrete components with well-defined interfaces. That’s nice in theory. However, in reality – most project managers understand that project processes, components, tasks, and deliverables actually overlap and interact in ways that are never really dealt with in the PMI standards guidebook.

You say you need a project portfolio management tool by next Friday, so you ask someone to evaluate the options, try a few out and write up a cost benefit analysis.

Is that necessary or is just it buying you time in your procrastination of the decision-making steps and process?