How cloud computing is changing project management

Many organizations have started their cloud transition, but cloud computing is still new enough that project management practices have yet to catch up.

There aren’t a lot of resources available about managing cloud (transformation) projects, which is rather strange, because the way cloud computing works has a major impact on the skills a project manager needs to be successful in delivering such projects.

One of the first hurdles is recognizing that cloud computing is not a single technology, product, or design – it really is a new approach to IT and doing business. I am not a big fan of bullshit bingo, but this you really can call a paradigm shift.

Some projects configure cloud services as a private cloud, while others use pre-defined public SaaS (Software as a Service), PaaS (Platform as a Service) or IaaS (Infrastructure as a Service) offerings. Of course, you can combine these in what are known as hybrid clouds, or join forces with other organizations in creating a community cloud.

Examples of typical cloud projects include:

> Converting to an external hosted business application, such as Salesforce;

> Implementing Microsoft Office 365 in the cloud;

> Creating a cloud-based server/storage infrastructure as a standard resource for corporate users;

> Establishing a standard program testing platform and deploying a set of development tools for cloud application development (i.e., creating a PaaS environment);

> Developing a new cloud-based enterprise application using an existing PaaS environment;

> Implementing a cloud-based data backup or disaster recovery system; and

> Acquiring a cloud-based security management system.

This article will describe what are, in my opinion, the 10 most important things you need to be aware of when managing cloud projects compared to on-premises projects.

Security & Compliance

You need to understand that a migration to the cloud will often completely disrupt an organization's existing security and governance strategy. Governance methods that worked for traditional on-premises systems probably won't work for the cloud.

As organizations move data to the public cloud, their control decreases and more responsibility falls on the shoulders of the cloud providers. Therefore, organizations must shape their security governance strategies to rely less on internal security and control, and more on their cloud provider's offerings.

Since security is never 100 percent perfect, it's important for you to plan ahead for potential breaches, failover and disaster recovery.

And of course, these additional security tools and services will increase overall project and operational costs.

Data Privacy & Residency

You need to be aware that there are laws in specific states, countries, or governmental associations such as the European Union (EU) that dictate that sensitive or private information may not leave the physical boundaries of the country or region (residency), and that the information should not be exposed to unauthorized parties (privacy).

Example legislation includes:

> The United Kingdom Data Protection Law

> The Swiss Federal Act on Data Protection

> Russian Data Privacy Law

> The Canadian Personal Information Protection and Electronic Documents Act (PIPEDA)

The EU Data Protection Directive is also an important piece of data privacy legislation that regulates how data on EU citizens needs to be secured and protected. With the European Court of Justice’s ruling in 2015 that the Safe Harbor framework is inadequate to protect the privacy rights of EU citizens when their data is processed in the United States, data privacy professionals expect to see additional data privacy legislation and restrictions appear across Europe.

Besides these general data protection laws, there are also industry-specific compliance requirements that can affect your project. Examples of such requirements include:

> The Health Information Portability and Accountability Act (HIPAA)

> Swiss Banking Secrecy

> The Health Information Technology for Economic and Clinical Health (HITECH) Act

> The Payment Card Industry Data Security Standards (PCI DSS)

And then there are third-party obligations: Agreements among business partners that outline how a party such as a contractor or vendor will handle and treat private or sensitive data belonging to another organization.

Such agreements often hold the external party accountable for securing the data in the same fashion as the owner of the data, including adherence to all residency, privacy, and compliance requirements.

For example, a contracted agency performing billing for a hospital in the U.S. must observe all the data protection requirements mandated by HIPAA and HIT.

Vendor Relationships & Contract Negotiation

While project managers have always needed to have contract negotiation skills, the move to cloud requires you to employ vendor relationship and contract negotiation skills much more often.

There is an aspect of additional overhead to this because the development of even a small application would necessitate working with the vendor to iron things out.

Cloud and SaaS vendors need to stay in business, and are not likely to cut customers slack in many areas. Buyers need to be prepared to assert their organizations' best interests on the questions of service interruptions, service-level agreements, data availability and physical location, and intellectual-property rights.

Service Level Agreements

Cloud computing involves a division of responsibilities between users and providers that needs to be based on well-defined agreements, usually called Service Level Agreements (SLAs).

Every cloud services provider has an SLA that specifies what is being provided, how well it should work, what remedies are available if it fails, and how much it costs. For example, Microsoft has its Azure SLA(s) and Amazon has its EC2 SLA.

Many project managers may not have had much prior experience with this type of agreement. You will when you are involved in a cloud computing project.
SLA concepts can be applied at three different interface points:

> End User/Solution Owner – an SLA between parties within the enterprise that specifies what the IT Department provides to its business customers;

> Solution Owner/Internal Provider (or a Broker) – an Operational Level Agreement (OLA) that codifies service agreements between departments or with a cloud broker; and

> Internal Provider/External Provider – an SLA between the organization and a cloud service provider.

Team Size & Skills

The size of local project teams has greatly reduced and the skillsets of those who need to stay onsite have changed. This means effective coordination and communication between location- and organization-dispersed teams becomes even more important than it was the last few years.

There are no internal team members involved in the design and architecture piece. You only interact with designers and architects from the vendor side remotely, with them coming onsite for meetings as needed.

The coordination overhead increases as you still have to take care of oversight responsibilities ranging from estimation through testing, but with external vendor personnel.

Financial Literacy

You will be required to deal with environments that are going to be a mix of applications hosted on onsite servers and those hosted at cloud sites. When a new application is to be developed, you need to perform cost and ROI analysis for both options. This requires knowledge of cost for cloud-based environments and expertise at creating both a detailed project budget and an operational budget.

This can be challenging, because a disadvantage of running things in the cloud is that costs can be wildly unpredictable. Public cloud providers, with the exception of most SaaS providers, are not known for using simple billing models. Typically, you are billed based on the resources you consume. This includes storage resources, but also CPUs, memory, and storage I/O. Resource consumption may be billed differently at different times of the day, and not all activity is treated equally.

Technical Proficiency

You don’t have to be an engineer or solutions architect to run a cloud-based project. That said, the more technical knowledge you have, the better. At the very least, it helps to know the differences between VMware, Azure, Google Cloud Platform and AWS, and how your company or vendor deals with these differences. After all, as the unified cloud becomes more of a reality, knowledge of gaps and bridges will only enhance your project skills and contribution to the project.

Due to the fact that the architectural landscape for applications gets more complicated after the move to the cloud, a deeper knowledge of the organization’s enterprise architecture comes in handy in order to ensure that newer applications get developed with the correct business and technical requirements in a manner that they work seamlessly with the existing applications hosted in the cloud and onsite.

Risk Management

The use of external providers, or a hybrid of internal and external services, can lead to additional business, technical, and project risks. Reputation and breaches of providers impact you more than ever. Sensationalized stories about data loss in the cloud, and publicized security breaches can make it difficult to gain support for cloud systems, especially public clouds; you as a project manager will spend a lot of time allaying fears, proving the solution, and generally providing answers to stakeholder questions.

Exit Strategies

Exit strategies need to be carefully thought out before committing to a cloud engagement. Vendor lock-in typically results from long-term initial contracts. Some providers want early termination fees (which may be huge) if organizations terminate a fixed-term contract earlier for convenience.

Often, contracts require "notice of non-renewal within a set period before expiry,” causing users to miss the window to exit the arrangement. Such automatic renewal provisions can be negotiated out up front.

Another way to avoid lock-in is to actually use several providers, to avoid over-reliance on one provider’s service and its (possibly proprietary) application programming interfaces.

Cloud-to-Cloud Migrations

Cloud migrations aren't just a transition from on-premises technology to the cloud; you can also migrate data from one cloud to another. These cloud-to-cloud migrations include moves from one provider to another, as well as migrations between private and public clouds. However, the migration process from private clouds to public clouds can be difficult.

While third-party tools are available to help, there is no comprehensive tool to handle the entire migration process. Cloud-to-cloud migrations involve considerable manual labor. To prepare for migration from one provider to another, organizations need to test their applications and make all necessary configurations for virtual machines, networks, operating systems and more.

Conclusion

For most project managers, managing cloud computing projects means entering unfamiliar territory. As you can see, the things a project manager needs to be aware of in order to be effective are different for cloud computing projects than for traditional on-prem projects. When considering a move to the cloud, you will need to skill up and learn about contracts, SLAs, laws, technology, and more.

This was the first article in a series about managing cloud projects.

Read more…

Stop wasting money on FOMO technology innovation projects

Big data, blockchain, artificial intelligence, virtual reality, augmented reality, robotics, 5G, machine learning... Billions and billions are poured into projects around these technologies, and for most organizations, not much is coming out of it.

And this is not because these projects are badly managed. Quite simply, it is because they should not have been started in the first place.

I believe that one of the main reasons that many innovative technology projects are started comes down to a fear of missing out, or FOMO.

FOMO is the pervasive apprehension that others might be having rewarding experiences that you are not. This social anxiety is characterized by a desire to stay continually connected with what others are doing.

FOMO can also be described as a fear of regret, which may lead compulsive concerned about the possibility of missing an opportunity for social interaction, a novel experience, a profitable investment, or another satisfying event.

In other words, FOMO perpetuates the fear of making wrong decisions on how you spend time and money, and it’s all due to your imagination running wild.

This fear is not limited to individuals. Organizations are victims of FOMO as well. And you will find that fear prominently on display in the many technology innovation projects that are started.

So before you start your next technology innovation project, please ask yourself the following fourteen questions. And if you’re not happy with the answers, don’t start spending time and money just because you fear missing out.

1) Why do anything at all?

First, be sure the project lies clearly in the direction your organization is heading.

It’s important to fully understand your organization’s latest strategies, priorities and targets. This helps prevent fundamental errors early on. Strategic thinking could even reveal larger opportunities than you first considered. After all, a complex technology project requires your very best people and a great amount of their focus.

2) Why do this exactly?

There are three basic ways to create value: earn more, spend less, or do things more efficiently. Decide what you’ll focus on and be able to explain why the project will do something meaningful towards that.

What customer do you want to serve with this solution? Will it involve selling more to existing customers, or pitching to entirely new ones? What job do you want to help them do better? Is the problem even big enough?

Clayton Christensen, the famed Harvard Business School professor known for coining the term “disruptive innovation,” believes that one of his most enduring legacies will be an idea he first put forward in his 2003 book "The Innovator’s Solution": don’t sell products and services to customers, but rather try to help people address their jobs to be done.

What if the benefits of the project are less tangible at this stage? Proceeding in order to gain market and product knowledge, develop new capabilities, find new partners and test possible models is perfectly valid. The challenge then is to articulate the benefits effectively.

3) What does success look like?

Before you start a project it's essential to work actively with the organization that owns it to define success across three levels:

i) Project delivery success is about defining the criteria by which the process of delivering the project is successful.

Essentially, this addresses the classic triangle of "scope, time, budget." It is limited to the duration of the project, and success can be measured as soon as the project is officially completed (with intermediary measures being taken, of course, as part of project control processes).

ii) Product or service success is about defining the criteria by which the product or service delivered is deemed successful.

For example, the system is used by all users in scope, uptime is 99.99 percent, customer satisfaction has increased by 25 percent, operational costs have decreased by 15 percent, and so on.

These criteria need to be measured once the product/service is implemented and over a defined period of time. This means it cannot be measured immediately at the end of the project itself.

iii) Business success is about defining the criteria by which the product or service delivered brings value to the overall organization, and how it contributes financially and/or strategically to the business.

For example, financial value contribution (increased turnover, profit, etc.) or competitive advantage (market share won, technology advantage).

Once these possible benefits are projected, examine whether those outcomes are realistic.

4) Will people pay for it?

This seems quite self-explanatory, but the amount of products that large organizations build for which there is little eventual market appetite is not to be snickered at. You want to build prototypes to not only validate the product/solution fit but also the revenue/pricing model.

5) Will it cost less to deliver than people are willing to pay for it?

What's the cost of delivery per customer and customer acquisition cost? You need to understand this and compare it to the lifetime value generated per customer. If each customer is worth approximately $1 million but it costs us $1.1 million to deliver said product, then you're operating at a loss and need to rethink your business model.

6) Is there already an effective but ‘less innovative’ solution to your problem?

Many of the problems we try to solve in technology already have solutions that we know work. For example:

> WORM storage vs. Blockchain when it comes to immutability
> Simple scripts vs. expensive RPA solutions

These solutions are not new and we have plenty of data to show that they are effective in solving the problem that they’re trying to address.

If the problem that you’re looking to “solve” already has proven and effective solutions, then maybe you don’t need an innovative new idea. You just need more funding for boring solutions that actually work.

7) Has it been done before? 

It's important to look at already available analogs (other products that validate market appetite) and antilogs (products that invalidate market appetite).

For example, analogs for the iPod were the Sony Walkman (these validated mobile music consumption) and MP3 players (these validated that people would download MP3s to external devices). Likewise, you want to identify failures and understand why they failed and whether or not this learning presents an opportunity.

Be aware that other organizations may have already attempted the innovation that you are advocating, and failed. One of the problems we face in development is that not all failures are reported, making it hard to learn from all that has come before us.

8) Are you trying to solve the underlying problem using only technology?

Technology can do many things to an existing process. For example, it can:

> Make the process faster
> Make the process more reliable
> Store lots of data
> Make the process more interactive
> Allow people involved to communicate more easily.

However, technology alone cannot solve an underlying problem. Taking a bad system and replicating that bad system with better technology won’t necessarily lead to improvements.

In my experience, the most effective innovation projects are ones that make incremental improvements to an existing process or system using technology (e.g., making the process faster, more reliable, etc.).

A fundamental requirement is that people are already using the existing system. If they don’t use the existing system, then they probably won’t use the new one.

9) Can you test it relatively quickly, economically and effectively using your existing networks and ability to prototype?

If you can't, then you won't be able to move quickly enough and may over-commit time and money to something that there may be little appetite for. However, today all it takes is a little imagination to build prototypes for even the most ambitious technical endeavors. The first prototype for Google Glass was built in just one day.

10) Is this scalable?

If you are successful in finding product market fit and validating your business model, what will it take to scale up by 100x, 1,000, or 10,000? Can you scale, or do you need funding and partners? How would you go about that? Would scale affect your business model and what makes your company tick? What would be the cost per unit if you scale? Will your business model still make sense?

11) Why not wait?

Why act now? You need to be able to explain why failure to act now will threaten the organization.

There is often less risk in not being first to market. Competitors can react quickly and effectively, simply learning your methods and replicating your gains without making large investments themselves.

The net result then could be restricted to temporary market share gains and, potentially, lower long-term industry prices. Even if you’re seeking to respond to a new functionality launched by a competitor, be sure of why you can’t wait to see their market reception before initiating action.

If the additional revenue gains are not large enough to win sufficient internal support over other opportunities, you must be able to point to other reasons that compel action now.

12) Who could or should do this internally?

Often, the source of innovation is not where the execution ability sits.

Identify which internal departments need to be involved. If the project proceeds, they will hear about it anyhow. It’s better to learn from their perspective and insight early on.

This is also important if you need both central corporate and local divisional sponsors, and it is unclear where the full cost should appear.

13) Who externally could do this better?

Determine if you have the necessary skill-sets internally to achieve the optimum outcome.

It is expensive and risky to create an entire new platform yourself unless the opportunity is large enough. Can you outsource some of the components involved? Instead of developing new systems, could licensing or working with a third-party vendor improve speed, flexibility, and scalability? Maybe you could buy a startup in the space you are looking for.

14) What else could I do instead?

In a competitive trading environment with constant pressure to innovate, the project generation, review, and approval process often only involves a few individuals. This may help with focus, but it also removes valuable alternative perspectives.

Project sponsors should actively seek alternative views and ensure relevant experts are consulted. It is much more persuasive if project sponsors show they have thoroughly considered alternative, organic growth strategies.

Conclusion

Is the why greater than the how?

Ideally, organizations should only do as many things as they can do well.

You should, of course, ensure that you are exploring all opportunities that create value for the organization. However, once a growth area is identified, the key to making the right decision depends on many variables and estimates, as well as the judgments of senior executives.

You may find these deceptively simple but powerful questions quite useful in testing and refining technology project proposals, clarifying the business case, building support, and ultimately persuading others why they should invest scarce resources in an idea or not.

Read more…

Power, politics, and getting sh!t done as a project manager

Leadership and management are ultimately about being able to get things done. Your skills and qualities as a project manager help you to achieve the project goals and objectives. One of the most effective ways to do this is through the use of power. Along with influence, negotiation, and autonomy, power is one of the key elements of politics.

Power and politics are probably the most important topics in project management, but at the same time, they’re one of the least discussed subjects. They are neither “good” nor “bad,” “positive” nor “negative” alone. Each organization works differently, and the better you understand how the organization works, the more likely it is that you will be successful.

Politics has a bit of a dirty name. It’s associated with false promises, backstabbing, alliances and manipulating others. But the worst weakness of politics is its failure to deliver on its promises. Time and time again we see public politicians or business leaders failing to deliver the change they promise. And we as project managers do as well.

Power, in the engineering sense, is defined as the ability to do work. In the social sense, power is the ability to get others to do the work (or actions) you want regardless of their desires.

When we think of all the project managers who have responsibility without authority, who must elicit support by influence and not by command authority, then we can see why power is one of the most important topics in project management.

Power can originate from the individual or from the organization. Power is often supported by other people’s perception of the leader. It is essential for you to be aware of your relationships with other people, as relationships enable you to get things done on the project.

There are numerous forms of power at the disposal of project managers, but using them can be complex given their nature and the various factors at play in a project. Some forms of power are:

> Positional (sometimes called formal, authoritative, legitimate; e.g., formal position granted in the organization or team);

> Informational (e.g., control of gathering or distribution);

> Referent (e.g., respect or admiration others hold for the individual, credibility gained);

> Situational (e.g., gained due to unique situation such as a specific crisis)

> Personal or charismatic (e.g., charm, attraction);

> Relational (e.g., participates in networking, connections and alliances);

> Expert (e.g., skill, information possessed, experience, training, education, certification);

> Reward-oriented (e.g., ability to give praise, money, or other desired items);

> Punitive or coercive (e.g., ability to invoke discipline or negative consequences);

> Ingratiating (e.g., application of flattery or other common ground to win favor or cooperation);

> Pressure-based (e.g., limiting freedom of choice or movement for the purpose of gaining compliance to desired action);

> Guilt-based (e.g., imposition of obligation or sense of duty);

> Persuasive (e.g., ability to provide arguments that move people to a desired course of action); and

> Avoiding (e.g., refusing to participate)

Effective project managers work to understand the politics inside their organization, and are proactive and intentional when it comes to power. These project managers will work to acquire the power and authority they need within the boundaries of the organization’s policies, protocols, and procedures rather than wait for it to be granted, or not given at all.

Read more…

Why killing projects is so hard (and how to do it anyway)

It was to be a great digital leap for Germany’s biggest discount grocer. Instead, after seven years and €500 million in sunk costs, the project tasked with creating Lidl’s new inventory management system with SAP was killed in July 2018.

In planning since 2011, the project quickly lost its shine when roughly a thousand staff and hundreds of consultants started the implementation. The costs quickly spiralled beyond the two groups’ estimations without bringing the project much closer to success.

Not every project makes its way to the finish line, and not every project should. As a project manager or sponsor, you’re almost certain to find yourself, at some point in your career, running a project that has no chance of success, or that should never have been initiated in the first place.

The reasons why you should kill a project may vary. It could be the complexity involved, staff resource limitations, unrealistic project expectations, a naive and underdeveloped project plan, the loss of key stakeholders, higher priorities elsewhere, market changes, or some other element. Likely, it will be a combination of some or many of these possibilities.

Why killing projects is so hard

When it comes to killing projects, a number of obstacles can get in the way, leading to projects being killed too late or not at all.

#1 Ego

Most people want to succeed. After putting time and effort into a project, no one wants to give up without a fight. Being labeled a quitter can mar an otherwise stellar career. As a result, some projects continue long after it becomes apparent that significant problems exist.

And when multiple parties collaborate to produce an outcome, the many points of failure exacerbate the situation.

Ego is a big part of our professional lives, because no one wants to fail, and certainly not in public. If it was your idea to start a project, it's tough to say, 'I was wrong.' However, project managers and sponsors should set aside ego and reevaluate projects based on costs and benefits, no matter whose idea it was.

#2 Ownership

People who have ownership of a project often aren't objective about it. They get too close to the project and become emotional about it, taking it personally.

If 20 people are working on a project for a year, they feel invested in the outcome and want to bring the project to fruition no matter what. Telling that group that its work is headed to the trash heap sounds like failure. You’re killing their “baby,” and it might be difficult for them to accept.

#3 Momentum and inertia

Newton’s first law of motion states:

When object at rest stays at rest and an object in motion stays in motion with the same speed and in the same direction unless acted upon by an unbalanced force.

The bigger the mass and the faster the object is moving, the more force you need to apply to stop or divert it.

Often, projects are not killed simply because they are close to being completed, and the desire to check the final few boxes and declare the finished project a success may outweigh the fact that the project is not very useful.

People's natural inclination is to focus on the positive. The question we ask ourselves is, 'How do we save this project?' instead of, 'Should we be killing this project?'.

#4 Culture

It's easy to kill a project if the culture is one of taking risk and understanding that some projects will work and others will fail. Such a culture will help you look at those projects as learning opportunities rather than failures.

But most organizations are far away from having such a culture, and tend to play it safe rather than abort something they’ve invested valuable time and resources in, even if it’s doomed to failure.

#5 Sunk costs

The decision to kill a project should be based on future tasks and future value. Sometimes, a project continues because of money already spent. When time and resources are invested, no manager wants to stop a project. But that money isn't coming back.

The focus should be on how much more needs to be done, or how much more needs to be spent, and what benefits would accrue from the project once completed. If those benefits do not exceed the costs of taking it from here to completion, then you should kill it, regardless of the money spent already.

#6 Fear

Killing our own project is scary. We are afraid of losing the respect of our peers, a promotion, or even our job. We are afraid of the unknown, of what happens next.

How to do it anyway

Whatever the underlying reason for keeping something going might be, knowing when a project is doomed, and knowing how to end a project gracefully, are essential skills for any project manager or sponsor.

Killing a project is never a fun or rewarding process, but the alternative—allowing a hopeless project to linger for months (or even years), continuing to consume valuable resources—is even worse.

The strategies listed below will help you when it’s time to put an early end to a project.

#1 Understand the impact to the organization

Ending a low-priority, low-visibility project can be very simple — a quick meeting or two with project stakeholders, a bit of documentation to tie up the loose ends and you’re done.

Killing a project with a large budget, large project team and high level of involvement at the executive level, on the other hand, is enough to rattle the nerves of even the most confident project manager and sponsor.

Before you take any steps toward ending a project, think about who will need to be involved in the decision, who should hear the news first and what (if any) contingency plans will need to be put in motion.

#2 Don’t play the blame game

Usually, when a project needs to be terminated, a number of people have made (big) mistakes somewhere along the way. No matter who’s to blame, you won’t do yourself any favors by pointing the finger.

Your end-of-project report should give an accurate description of the reasons that the project needed to be killed, and that’s all. Any unnecessary or excessive details about mistakes by team members, executives, vendors or anyone else will give the impression that you’re trying to deflect blame from yourself.

#3 Establish a process

Implement a decision-making process to shut down non-functioning projects. If a temporary endeavor fails to progress on schedule or produce intended results in a timely manner, it’s time to close the project and consider re-allocating its resources towards starting a new effort.

You need to have somebody on the team whose focus is always about, 'Is this reality? Can it get us to where we want it to?' Without a formal process, team members may assume they have to continue until the documented end of the project.

#4 Set a time bomb

Set a time bomb for your project. Essentially, it’s an exploding deadline that forces you to kill your project if it doesn’t get to the level of success you want by a specified time.

If _______________ (project name) doesn’t achieve  _______________ (directly measurable metric of success) by __/__/____ (specific date less than 6 months in the future), _______________ (project name) automatically shuts down. We will cease future work on it and the automatic consequence goes into effect and I have to shoot my project in the face (figuratively) and walk away.

This is extra tough when you have a project that’s not necessarily bad, but may not be the best project, either.

#5 Fail fast and kill early

Try to kill as many projects as possible as early as possible.

Ask yourself the following question: "What must be true for this project to be successful?"

In most projects there are probably thousands of things that must be true as well, but generally no more than four to five items control the success of a project.

Validate these assumptions and if they prove to be false, you’ll know the project doesn't have any legs to stand on and you should kill the project on the spot by not allocating any more money or talent to it.

The beauty of this approach is that you can get answers to these questions by conducting small and inexpensive tests to give you a sense of whether your new product will be successful or not.

#6 Get buy-in from stakeholders

Before terminating an unworkable project, ensure that the stakeholders are all on board with the decision as well as the reasoning behind it. Everyone involved should come to a consensus regarding how and when to end the project before it’s announced to the rest of the company or management. No one involved with the project should encounter any surprises when it is terminated.

If possible, announce the decision collectively as a group, so no one person or entity is seen as being to blame or being naysayers.

#7 Face reality

Ironically, ending a project is easy if the project simply can't be done. Enumerate the strategic reasons why it's not possible; perhaps the technological concepts behind the project aren't sufficient, security constraints or requirements are too prohibitive, cost has grown prohibitive or some other factor renders the project objective unobtainable.

However, tread with caution here, because if this is performed clumsily, the project originators could give the impression of being poor planners for not knowing something was impossible before launching a project based upon it.

#8 Communicate what's inside and what's outside your control

If conditions changed during the course of the project and rendered it impossible (for example, a key vendor went out of business, or a discount thought to be valid turned out otherwise and inflated the costs), make sure to include this information in the announcement.

Similarly, if the project needs to be canceled because staff lacks sufficient knowledge at present, be honest and upfront about this—but see if you can rectify the situation to revisit the project down the road. If it's within your power to change the situation in the future, make every effort to do so.

#9 Focus on business impact

When canceling a project, always approach the decision from the angle of doing what's right to deliver the best value to the business by not wasting capital or resources on an initiative with lower payoff than you expected.

The goal is to make it clear you're not shirking work simply due to a complexity factor (nobody wants to be seen as unwilling to follow through on their objectives), but rather that you’re acknowledging you've gone down the wrong path and are returning to the proverbial fork in the road to pick a different option.

The goal of a project is always to do what's best for the company, rather than pursuing its own ends or striving to save face.

#10 Focus on the financials

If you can achieve cost savings by shutting down a non-workable project, make sure to enumerate the details. Hopefully if you're pulling the plug in the midst of a proof of concept or demo phase, any investment in hardware, software, support and other elements is minimal or non-existent.

If a project can be completed but it would be too costly to do so (or the expected outcome would not be up to par), provide details regarding the return on investment to explain why it's not feasible. Don't forget to factor in the expected labor as well as actual costs, since that constitutes an expense for the company as well.

This may be painful if you lobbied hard that the project would in fact save money down the road, but it's important to realize that circumstances change and, again, your job is to do what's best for the company, not what's advantageous to your reputation in the short-term.

#11 Create a supporting culture

People that kill projects should not be punished. They should get a spot bonus from their manager. They should get promoted because of it, not despite it. They should get exciting new jobs — as soon as a project closes down, people get snapped up by other projects.

In other words, remove the fear and make it safe for people to kill their project.

If you are a project manager or sponsor, it’s your job to remove as much inertia and fear as you can for your team.

Conclusion

Knowing when to kill a project and how to kill it is important for the success of organizations, project managers and sponsors.

Keep an eye out for warning signs, ask yourself tough questions, and set aside your ego. By doing so, you can easily identify projects that need to be abandoned right away.

Closing failed projects might not be the easiest thing to do but if you know how to kill it the right way, it won’t be a problem.

Have you ever killed a failed project? What were the reasons? What do you believe is the right way to kill a failed project? Feel free to share your project management experiences in the comments section below.

Read more…

Case Study: The £10 billion IT disaster at the NHS

The National Program for IT (NPfIT) in the National Health Service (NHS) was the largest public-sector IT program ever attempted in the UK, originally budgeted to cost approximately £6 billion over the lifetime of the major contracts.

These contracts were awarded to some of the biggest players in the IT industry, including Accenture, CSC, Atos Origin, Fujitsu and BT.

After a history marked by delays, stakeholder opposition and implementation issues, the program was dismantled by the Conservative-Liberal Democrat government in 2011, almost 10 years after Prime Minister Tony Blair initiated it at a seminar in Downing Street in 2002.

The core aim of the NPfIT was to bring the NHS’ use of information technology into the 21st century, through the introduction of integrated electronic patient records systems, online ‘choose and book’ services, computerized referral and prescription systems and underpinning network infrastructure.

Despite the failure of many of these services to be delivered, the government, and ultimately taxpayers, incurred significant costs for the program, including contract transition and exit costs which continued to accrue to a total amount of more than £10 billion.

Since NPfIT was a public-sector program, there is a large amount of documentation and press about the case available. If you are interested in reading more about it, I have collected many of these documents here.

This article is a summary of one of these documents that I would recommend any project manager to read: “The National Program for IT in the NHS: A Case History” by Oliver Campion-Awwad, Alexander Hayton, Leila Smith and Mark Vuaran. You will find the document in the directory mentioned above.

This excellently written case history of the NPfIT investigates what went wrong with the program. It identifies three main themes:

1) Haste

2) Design

3) Culture and skills

The rest of this article will look into these into more detail.

Haste 

In their rush to reap the rewards of the program, politicians and program managers rushed headlong into policy-making, procurement and implementation processes that allowed little time for consultation with key stakeholders and failed to deal with confidentiality concerns. This resulted in:

> An unrealistic timetable

> No time to engage with users and privacy campaigners

> Inadequate preliminary work

> Failure to check progress against expectations

> Failure to test systems

Design

In an effort to reduce costs and ensure swift uptake at the local levels, the government pursued an overambitious and unwieldy centralized model, without giving consideration to how this would impact user satisfaction and confidentiality issues. This resulted in:

> Failure to recognize the risks or limitations of big IT projects

> Failure to recognize that the longer the project takes, the more likely it is to be overtaken by new technology

> Sheer ambition

> The project being too large for the leadership to manage competently

> Confidentiality issues

Culture and skills

The NPfIT lacked clear direction, project management and an exit strategy, meaning that the inevitable setbacks of pursuing such an ambitious program quickly turned into system-wide failures. Furthermore, the culture within the Department of Health and government in general was not conducive to swift identification and rectification of strategic or technical errors. This resulted in:

> A lack of clear leadership

> Not knowing, or continually changing, the aim of the project

> Not committing the necessary budget from the outset

> Not providing training

> A lack of concern for privacy issues

> No exit plans and no alternatives

> A lack of project management skills

> Treasury emphasis on price over quality

> IT suppliers that depend on lowballing for contracts and charge heavily for variations to poorly written specifications

Conclusion

When you compare the results of this case study with my personal top ten reasons of technology project failure, you will recognize that almost every one of these ten reasons was an issue within the NPfIT.

1) Poorly defined (or undefined) done.

2) Poorly defined (or undefined) success.

3) Lack of leadership and accountability.

4) No plan or timeline.

5) Insufficient communication.

6) Lack of user and performance testing, or failure to address feedback.

7) Solving the wrong problem.

8) Trying to adapt standard software to business processes instead of the other way around.

9) Continuing to pursue bad ideas.

10) No real decisions and death by committees.

When you want to prevent your own project from becoming a disaster keep this list in mind and do the opposite. You will find further reading in the mentioned article.

On top of these, you should always keep your projects as small as possible. The bigger they are, the higher the chance of becoming a disaster.

And remember that there is a reason why risk management is called project management for adults.

Read more…

17 Lessons Project Managers can learn from Crisis Management

In my spare time, I enjoy reading books on topics from other industries or disciplines that are related to project recovery and project management. One of the disciplines that I like to read about is crisis management. The reason is probably pretty obvious. Many of my engagements as a project recovery consultant start with a project in a crisis situation.

Over the years I have read quite a number of articles and books on crisis management and from them I have distilled a set of principles and practices that are valuable for project managers. Besides these principles and practices, I have written down my own lessons learned from project crisis situations.

These combined notes have helped me a lot over the years, and I think they can help you as well. Read on for my 17 lessons on effective crisis management for project managers.

Lesson #1: Immediately respond to early warning signs.

Before any negative event occurs, there are always some signs. Your job is to learn to detect those signs and take immediate preventive actions.

Be aware of persistent customer, stakeholder or project member complaints; rumors; turnover in the project; and resistance to change due to innovation or technology. These issues always seem to start off small and begin to swell. Don’t ignore them, and dig in to find out if there is the potential of a problem coming at you.

Once you have detected warning signs, you need to develop a plan of preventive actions to eliminate the problem, or at least to minimize its negative impact to the project. Usually such actions are specified in your risk management plan. A good project manager has such a plan.

Lesson #2: If you can’t prevent a crisis, at least contain it.

After a crisis has occurred, you will want to contain it as quickly as you can by getting accurate information as to what was the real cause of the crisis and what the ramifications are. Next, you need to act quickly and decisively, communicating correctly to all levels of the organization while behaving ethically as you attempt to contain the crisis.

Lesson #3: Make decisions as quickly as possible.

During a crisis, your decisions should be made quickly because you do not have time to conduct a deeper analysis of the problem. Meanwhile, the decisions should be well weighted. Remember, you shouldn’t act as quickly as possible, but you should make a quick decision.

Lesson #4: Be realistic but optimistic.

When a crisis happens, don’t panic! If you become very pessimistic during the crisis, your project is likely to fail because you won’t be able to generate effective solutions and make quick decisions. So be optimistic when seeking solutions.

A realistic assessment of the situation will help you find feasible workaround solutions. Your optimism will inspire the team with enthusiasm so they will be ready to follow your lead and carry out your instructions of effective crisis management.

Lesson #5: Never run out of altitude, airspeed and ideas at the same time.

To ensure your project does not come to a screeching halt during a crisis, you should keep attention on the following three areas:

Altitude – This relates to maintaining focus on the big picture required for the leadership of a project such as project vision, critical thinking, ability to prioritize, motivation, and continually moving forward to accomplish objectives.

Airspeed – This relates to the velocity and forces that make a project go forward such as building relationships, having a good sense of humor, creating motivation through follow-through, being willing to listen, having the capacity to convey respect to others and their ideas, and having the confidence to tell project team members what they need to know. All of these fuel us to provide the airspeed to keep the project moving onward.

Ideas – This relates to your ability to brainstorm and incorporate creativity, maintain enthusiasm while challenging existing processes, and invite input from others from a variety of perspectives, as well as your willingness to try novel approaches and champion innovation. 

Lesson #6: Face reality.

There comes a time when you must formally acknowledge that a crisis has occurred and communicate this to everyone. Don’t ignore or deny the urgency and severity of the crisis; rather, confront it and take charge of the situation. Don’t blame other people or external events for the cause of the crisis. Your job is to resolve the situation as best you can.

Lesson #7: Legal threads are reputational threads.

All legal threats—e.g., threatened lawsuits, regulatory investigations—are potential threats to your organization's reputation and should be brought to the attention of whoever is responsible for reputation management/PR as soon as they're identified.

Typically, however, legal counsel and even senior company management delay notifying their  PR advisor, internal or external, until the shit hits the fan or will do so imminently. Rushed consideration of PR strategy and messaging is seldom as good as that which can be produced given more lead time.

"The court of public opinion can destroy your organization much more quickly than a court of law” —Jonathan Bernstein

Lesson #8: Take ownership of communications.

When a crisis takes place, people in the organization and project look for leadership to take charge. That is you, the project manager. Your task is to tell the facts, to define the situation and to provide hope that the situation is in good hands. The project manager should consider what needs to happen to lessen the crisis, what ambiguities needs to be cleared up, what needs to be communicated and what people are most concerned about. Be aware of your non-verbal body language so that it is in sync with both your spoken and written messages. People can sense when they don’t match.

Lesson #9: The big five of crisis communications.

The big five of crisis communications is a template for crisis communicators to follow and a standard by which the efficacy of crisis communications can be assessed. According to this template, crisis communications must be:

a) Prompt – or rumor and innuendo fill the gap.

b) Compassionate – if you don’t deal with people’s feelings first, they won’t listen to the facts.

c) Honest – no lying by commission, omission, or understatement, and/or exaggeration for the purpose of obfuscating the truth (“spinning”).

d) Informative – answering the basic journalistic interrogatives of who, what, why, when, where and how.

e) Interactive – in our digital age, providing stakeholders multiple ways to ask questions and engage in constructive commentary.

Lesson #10: Create a crisis management team.

The crisis management team (often called a task force) is responsible for the overall management and response to a crisis. This team should be created as soon as a crisis occurs, and it must include appropriate individuals from across an organization. The key to using this team is only activating it when necessary. Team members should know where to report to and their immediate responsibilities when the team is activated.

Lesson #11: Document all parts of your crisis management and actions.

Many crises will result in audits and intense internal, if not external, investigations of why a crisis occurred, how it was handled, and what could have been done better. As a result, all crisis management plans and actions should be thoroughly documented in the record.

Lesson #12: Encourage and demonstrate transparency and honesty.

As a project manager, do you squash debate in favor of politeness or do you encourage robust differences of opinion? After a problem throws you off-course, you want to make sure that you get your project back on track as soon as possible.

You want your team and the stakeholders to be open and feel free to express any and all alternatives to solving the problems caused by the crisis.

It is also much wiser to encourage and even reward internal whistle-blowing than to find  yourself at the wrong end of news coverage, a lawsuit and/or a governmental investigation prompted by a whistle-blower.

Lesson #13: Know your limitations.

During a crisis, you can feel overwhelmed with responsibility and many project managers are tempted to try to solve the problem all by themselves. Knowing your strengths and weaknesses and admitting to your limitations will actually benefit you. Acknowledge them, and it will enable you to find the right people to help you resolve the situation. This action will in fact strengthen your leadership ability since nobody really expects you to have all of the answers or go it alone.

Lesson #14: Respond appropriately to the media.

When a very serious crisis occurs, many large organizations have public relations (PR) specialists who respond to the press, but they need the detailed facts before taking action. You, the project manager, need to:

> Cooperate with the PR specialists and not obstruct their discovery efforts

> Minimize the lag time between the time the problem occurred and the response needed

> Gather the facts as quickly as you can

> Avoid responding to unfounded stories

> Be transparent and avoid “no comment” situations. If you don’t know, then say you don’t know and convey that you will find out the answers as soon as possible

> Avoid minimizing the situation by comparing it to worse ones. Remember the PR disaster after the BP oil spill?

> Communicate effectively and don’t try to confuse the facts

Lesson #15: Sometimes it's wiser to make peace than to be right.

Don't get into a public spat with government agencies or the media. They carry bigger sticks than you do, and they have long memories.

Lesson #16: Have a spokesperson trained before you need one.

The ability to make a flawless personal presentation to 1,000 people at a conference does not, automatically translate to an ability to conduct an on-camera media interview related to a crisis. Training is essential.

With rare exception, media interview skills are not part of a CEO's scholastic experience, and even if they were, if the CEO hasn’t kept up with them they have certainly eroded to the point of uselessness.

Effective spokespersons in a crisis must come across as compassionate, confident and competent.

Lesson #17: Learn from your crisis.

A crisis is unfortunate, but it provides an excellent learning opportunity for an organization, its employees, its upper-level management and its stakeholders. When each crisis is over, draft a set of recommendations and “lessons learned,” which can be used to prevent and effectively manage future crises.

If you don’t engage in a thorough post-crisis analysis, your crisis preparedness and response is unlikely to improve – ever.

Over the years, these 17 principles and practices have helped me to stay focused and on track when faced with a crisis situation in project management. I hope that they will prove useful to other project managers ans sponsors, and help you to mitigate and contain any crisis situations that come up in your organization and its projects. 

Read more…

7 Technology Project Management Trends and Predictions for 2019

As the old saying goes, “The only constant is change.” And nowhere does that sentiment seem to hold more truth than in the field of technology and the projects that implement technology.

The biggest shaping trends in technology project management that I see for the year 2019 are:

1) Approaches will be more tailored to projects.

2) Skills will start to be more important than certifications.

3) Remote working will continue to increase.

4) Stronger focus on the benefits of projects.

5) Cloud acceptance in all industries.

6) Attitude regarding data privacy and security is changing.

7) Growth of the project manager’s influence and responsibility.

Approaches will be more tailored to projects

For decades, executives believed that the best way to control project management from the top floor of the building was to create a single project management methodology that could be applied to all projects.

But with an increasing demand for flexibility to adapt and roll with the punches, organizations will move away from pre-set and rigid project management approaches.

Project managers should have always been making the best methodology choices for their projects, but some organizations didn’t lend themselves to doing so.

Now, those organizations will embrace tailoring in a way that forces project managers to make more choices about how to best run their project.

This shift means that project managers will have to lean on their own critical-thinking skills and professional judgment more than ever before.

Many organizations are already witnessing the positive impact of giving project managers room to customize their own methodologies.

Skills will start to be more important than certifications

While certifications will still hold some importance—especially for more traditional employers—they may no longer act as the be-all and end-all for landing project management roles.

A credential like the PMP certification is a valuable asset to boost your pay packet and demonstrate your expertise, but experience and skills—particularly technical and leadership skills—will carry far more weight with employers than they did in the past.

I am of the opinion that, in order to lead a strategic technology project, you need:

> to understand technology
> to understand the business
> to have project management skills
> to have leadership skills

Most certifications only look at project management skills, and only by testing whether or not you can memorize a book. With agile certifications it is even worse—you only have to memorize 20-something pages.

Project managers that are able to learn and adapt by working and thinking flexibly are the ones that are going to be the most successful at delivering projects. When it comes down to it, the foreseeable future is going to have a need for project managers that are comfortable walking across shifting sands.

Remote working will continue to increase

The International Workspace Group (IWG) found that 70 percent of the world’s workers work remotely at least once a week. Remote working is becoming more and more commonplace, so we expect to see project managers adopt it in greater numbers in 2019. Although project management offices (PMOs) will continue to grow in popularity, it’s very likely they won’t all be physical offices.

Not being bound to a workplace, whether as a permanent employee or a contractor, helps workers become more adaptable and blend their work and home lives together in a way that suits them.

Project managers will benefit from having access to a much wider team candidate pool without having to manage offices abroad or travel frequently. Having the freedom to hire around the world will require them to maintain high standards of visibility and communication for their teams.

In addition, the role of project manager will become more flexible and remote working will become more widely adopted.

While a team of curated staff is ideal, if that team’s members operate in different time zones and/or different languages, it brings its own new challenges. A great deal of scheduling and performance tracking is needed to keep a project on track when that project is dispersed around the globe.

A stronger focus on the benefits of projects

Competitive pressures and the volatility and uncertainty of the operating environment are feeding an increasingly competitive atmosphere in the marketplace. Technology in particular is creating winners and losers. Senior executives are on the lookout for anything that may provide a competitive edge.

Blockchain? Big data? Internet of Things? 5G? Artificial intelligence? It’s a bit like ‘project fear’, because nobody wants to miss the next big thing and get left behind.

When commissioning projects that are intended as transformative or that make a lot of promises, there is now a heightened need for results that really measure up against what was envisioned.

Organizations are going to want more return on investment from project spend.

It used to be that ‘on time and on budget’ was the universal standard by which to measure whether a project was a success. However, this is no longer the case. The coming year is going to continue to see a requirement for projects to deliver results which support the long-term strategic goals of the organizations that commission the projects.

Cloud acceptance in all industries

Forget internal servers; the cloud is the panacea. While you can’t reduce the discussion to this simple phrase, it is a fact that more and more companies are switching to systems in the cloud. And sooner rather than later.

The fears of not being able to reach the system at a critical moment, insufficient performance, and external unauthorized data access seem to have relaxed somewhat.

Of course, there are industries that don’t want to rely on cloud-based server solutions due to extreme secrecy, but they are fast becoming the minority. Many banks, insurers and auditors have already made the switch, and even the Pentagon has joined the cloud revolution.

The attitude regarding data privacy and security is changing

Regarding data security, those responsible in the organization are beginning to understand one thing: The biggest security hole is not technology but man. Successful hacker attacks on the server infrastructure of Microsoft, for example, are less likely to occur than data piracy committed by a disappointed employee.

Regarding data privacy, GDPR and related laws will continue to play a big role in technology projects. Also, the scrutiny on companies like Google and Facebook when it comes to their handling of data privacy will have a continued impact.

The growth of the project manager’s influence and responsibility

The organizational structure of many companies is now becoming less hierarchical. That is why often project managers take on part of the responsibilities of middle and executive managers.

Among the many tasks carried out by a project manager, strategic thinking is becoming one of the most critical.

Project managers will continue to be the leaders and managers who manage the creation of value, drive change, and are responsible not only for financial results but also for the vision of the project.

Conclusion

It’s clear that these trends, considered in a historical context, are part of a running narrative that has been evolving over the last few years. In truth, there is nothing really new here.

But what is clear is that these trends all tie together and make sense as they support two central ideas:

1) Project management is being shaped by the problems that need to be solved and not the other way around.

2) Projects drive change, and change drives projects.

Read more…