Wednesday, February 27, 2019

I bet your large technology project will be late and costs way more than you expected

I bet your large technology project will be late and costs way more than you expected
Yes, I am willing to make that bet without knowing anything about your project, your team, your organization, your timelines, or your budget. Here is why:

Activities within technology projects are usually so complex that if you were to repeat them under identical conditions, the time required to complete them would vary. After all, people are involved in performing these activities, and as you may know, the behavior of people is non-deterministic.

When you estimate or guess the duration of an activity, you're really dealing with a range of possible outcomes. If plotted as a distribution, the actual results for a number of identical trials would have a shape such as that shown in the figure below. There's a minimum duration, a most likely duration, and a maximum duration.


The shape of this distribution varies with the nature of the activity. For example, if you’ve done the activity many times and everything involved in it is fairly predictable, the minimum and maximum duration are close together. Though the distribution is probably very narrow.

If the activity has never been tried before and some aspects of the execution are poorly understood, the minimum duration and maximum duration might be more widely separated. Our time needed for the activity could be quite variable.

For example, setting up a GitHub repository is an activity that's well understood (at least by most developers). If you measure the time required by experienced professionals to setup such a repository, you would probably arrive at a fairly narrow distribution. On the other hand, building your own source code repository is an activity that is not well understood. The distribution of durations for that activity are more likely to be fairly broad.

Distributions for the duration of less predictable activities have another significant feature. Although the minimum duration is probably well below the most likely duration, the time between them is usually far less than the time between the most likely duration and the maximum duration. The distributions are likely to have shapes like the one below.


These long-tailed distributions are very normal. While there are some pretty hard limits on how fast things can be done, there are no limits on how slow things can be done. For example, no matter how hard you try, you probably cannot get your Windows laptop booted and working with a projector in less than 2 minutes; even if you pray. But even without trying, it can sometimes take you 20 minutes, even though it's only a small security update that is installing.

If you're prudent, you leave a little extra time to get yourself ready for presenting in that important meeting, and even then, you're just screwed.

This is just a small example. Now imagine the distribution of times required to integrate and test a complex API. If all goes well, it might take four weeks; rarely less. But if things don't go well, it could take months.

Why am I so sure it rarely takes less? I take into account Parkinson's law.

Work expands so as to fill the time available for its completion.

So why are projects always late?

The answer is that the estimates most of us make for the duration of an activity are of the "most likely" type. That is, we tend to use as an estimated duration for the most likely value of the duration. Since the most likely value of the duration is usually less than the mean duration, for most distributions in real life, we tend to bias our estimates towards the short end of the distribution, as illustrated below.


For a single activity, this isn't good, but it isn't a disaster. True, on the average, your performance would be less than stellar. Depending upon the exact shape of the distribution, you would find that typically, you would be underestimating the actual duration by about 10-20%.

The problem becomes much more severe when you look at projects in which the project duration is the result of several such underestimates, in a series, as would be the case along the critical path of a complex technology project. If you're significantly late on some activities, no amount of early delivery on other activities can compensate for it.

The Planning Fallacy

What I described above is one possible explanation for what is also known as the planning fallacy. First proposed by Daniel Kahneman and Amos Tversky in 1979, the planning fallacy is a phenomenon in which predictions about how much time will be needed to complete a future activity displays an optimistic bias and underestimates the time required.

This phenomenon sometimes occurs regardless of the individual's knowledge that past activities of a similar nature have taken longer to complete than generally planned.

Or as Hofstadter 's Law formulates it:

It always takes longer than you expect, even when you take into account Hofstadter's Law.

The bias only affects predictions about one's own activities. When outside observers predict activity completion times, they show a pessimistic bias, overestimating the time needed.

In 2003, Lovallo and Kahneman proposed an expanded definition as the tendency to underestimate the time, costs, and risks of future actions; while at the same time, overestimate the benefits of the same actions.

According to this definition, the planning fallacy results in not only time overruns, but also cost overruns and benefit shortfalls.

Conclusion

The above is why I will make the bet blindly; statistics seem to support my bet. According to multiple sources (KPMG Project Management Survey 2017, Standish Group Chaos Report 2015) more than 20% of large technology projects fail outright and another 50% are over time and budget. Also, the failure rate of projects with budgets over $1M is 50 percent higher than the failure rate of projects with budgets below $350,000 (Gartner).

Funny enough, almost 100% of all project managers and sponsors believe their project belongs to the other 25%.

In one of my next articles I will discuss some measures you can take to help mitigate the planning fallacy and make better estimations.

Read more…

Tuesday, February 19, 2019

How cloud computing is changing project management

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…

Tuesday, February 12, 2019

Stop wasting money on FOMO technology innovation projects

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…

Thursday, February 07, 2019

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

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…