7 Ways to increase IT Project success

Let’s face it – IT Projects have a bad reputation and an unenviable failure rate. It doesn’t have to be this way. Other industries do things better and in this article we uncover some of the principles for their greater project success rates. Specifically, we take a look at 7 of the strategies used in ‘Design Charrettes’ and how they could be applied in IT to great effect. If you’d like to improve your IT project success rate, read on.

7 Ways to Improve IT Project SuccessI’ve often wondered why IT Project Management seems to be plagued with failure after failure, yet project management as a profession in other fields seems to be relatively successful.

Of course we all recognise that IT is more craft than engineering. The variability in terms of users requirements, the vast array of technical solutions and combinations, and the fast pace of change, all certainly contribute to the difficulties and challenges. But is IT really that different from other disciplines?

How did we get here?

At Daysha we’ve been trying to figure this out and have discovered we can learn a lot from other disciplines. But let’s first take a brief look at where project management has come from.

The current top-down style of project management was formalized by the Project Management Institute in the 1970s. It is a style of planning and management that works well when a detailed project plan remains valid for the length of the project. And when you look at the origins of PM in construction, aerospace, and defence, you can see where this assumption could be valid.

Ray Levitt, Academic Director of the Stanford Advanced Project Management Program calls this PM 1.0 and says that

“PM 1.0 was developed to bring order and discipline to large teams of specialists engaged in a joint effort. They rested on the implicit assumption that the world was predictable and stable enough and that technologies for the development of projects such as dams, highways, pharmaceuticals, aerospace/defence were well enough understood that a ‘good plan’ developed by knowledgeable planners would remain a good plan for the duration of the project. Our PM 1.0 methods, tools and project organization cultures have largely taken this model of project management for granted, while the Internet-enabled worldview of today’s knowledge workers has been evolving under our feet, and key project assumptions that underlie our project plans are changing ever more rapidly in every dimension—technically, financially, politically, socially and even climatologically.”

So we need to recognise that our current project management paradigm was invented in the 1970’s, a completely different time and a different world. Are our project management practices still applicable? The industries which created project management have moved on and have adopted better techniques and tools. Don’t you think the IT industry should change also?

Now you might say -“But Chris, we have Agile, and Scrum, Lean, and Kanban, and many other ‘new’ techniques”. Yes. And these came from other industries (mostly derived from manufacturing). Yet even in IT projects using these methods, we see project after project fail. There’s still plenty of room for improvement.

What else can other industries teach us? While researching best practices in other fields I came across Design Charrettes. I’d never heard of this before and didn’t even know what a Charrette was. I almost skipped the google search results but after reading more I was intrigued. Here’s a brief primer.

Design Charrettes – A New Approach

A Design Charrette is a term used to describe a series of intensive workshops and collaborative activities in which various stakeholders and experts are brought together to address a particular design issue. Design Charrettes have been used by planning and design teams in the architecture and building planning fields for many years. In recent years they have been used in community and sustainability planning.

According to Joel Ann Todd, an Environmental Consultant, and Gail Lindsey, a Principal with Design Harmony “A charrette can be the mechanism that starts the communication process among the project team members, building (or campus) users, and project management staff. As such, it is important that all relevant decision makers attend. Furthermore, a charrette can be viewed as a creative burst of energy that builds momentum for a project and sets it on a course to meet project goals. It can transform a project from a static, complex problem to a successful, buildable plan.”

According to the NCI Institute, “A multidisciplinary charrette team, consisting of consultants and sponsor staff, produces the plan. Stakeholders – those being anyone who can approve, promote or block the project as well as anyone directly affected by the outcomes – are involved through a series of short feedback loops or meetings.”

Download Now

Learn How to Design Projects to Succeed.

The aim of these design charrettes is to produce a feasible plan where all stakeholders have agreed the objectives and all the stakeholders have a role in designing the solution. By conducting these early in the process, we can avoid mistakes and consequent rework later in the build. Due to their collaborative nature they tend to promote “collective enthusiasm” for a project with early realistic goals and directions.

If you ignore the fact that this is used in the context of building and community planning, I think the scenario sounds pretty similar to the situation we have with many IT projects; multiple stakeholders with the power to approve or block a project, users, project management staff, projects and goals, design, solutions, and rework.

If design charrettes can work in building planning, can the principles be applied in IT? So I researched some more to try to discover what it is that makes these design charrettes so successful.

7 Strategies

The NCI Institute lists the seven core strategies

  1. Work collaboratively
  2. Design cross-functionally
  3. Compress work sessions
  4. Communicate in short feedback loops
  5. Study the details and the whole
  6. Produce a feasible plan
  7. Use design to achieve a shared vision and create holistic solutions

1.    Work Collaboratively to increase buy-in

People collaborating at Pathfinder workshopInvolving all interested parties from the very outset of a project is critical, both in terms of understanding the project and in terms of commitment to the project’s objectives.  Collaboration establishes a solid foundation for the project’s success.

When all parties are included from the beginning of a project they know and understand how a project has arrived at the state it is in at any given point. They are aware of reasons for discarding particular ideas and why others are included. Because they have contributed from the outset, all parties also have a greater personal attachment and enthusiasm for the project.

For example, if implementing an enterprise wide IT system, we could form a team of representatives from all effected areas to agree the objectives of the project, review vendor solutions, and contribute ideas. This way all vested interests are represented, buy-in to the process, and don’t feel as though the system is being imposed upon them.

2.    Design Cross-functionally to reduce re-work

It is important to have a team with representatives from a broad spectrum of disciplines and business areas. Each will have their own unique and valuable viewpoint. Each team has the capability to arrive at decisions that take a more diverse range of factors into account. This results in a more streamlined process that eliminates the need for broader oversight. Each step of the process reflects the combined understanding of the different specialties involved. And in the end, since so many disciplines are represented, it is less likely that something will fall between the cracks and less likely that there will be a need for major rework down the line.

For example in a SW development project, we should include members of the user community in the team. This means they are full team members, not just invited to meetings or cc’d on emails. We should include designers, marketers, and support staff. Anyone impacted by the project should be part of the team. Daysha’s recent client experience clearly shows that cross functional design teams deliver more comprehensive design specifications faster and more efficiently.

This reminds me of the story of President Kennedy visiting the NASA space center in 1962. President Kennedy noticed a janitor carrying a broom. He interrupted his tour, walked over to the man and said, “Hi, I’m Jack Kennedy. What are you doing?” The janitor responded, “I’m helping put a man on the moon, Mr. President.” Perhaps a bit corny but it reminds us of the ideal attitude all team members should be striving for.

3.    Compress Work Sessions for faster decisions

Often in IT we spend too long agonizing over decisions – analysis paralysis results and before you know it you’ve burned a large portion of the budget. Using compressed work sessions we increase the speed of decision making. We are tapping into the fact that scarcity breeds innovation – if people know they have to make a decision within a certain timeframe, they will often come up with spontaneous and creative solutions because they have to abandon conventional processes.

Without a long process, solutions do not have time to become overly complicated by accommodating input from many different parties.

This is one of the underlying success factors in agile software development. By compressing work into sprints, there is no time to implement complex functionality. It encourages creativity and simplicity.

4.    Communicate in Short Feedback loops for improved momentum

Communicating throughout the process in short feedback loops works to complement compressed work sessions. Creating and presenting plans for review and refinement within hours keeps the process moving, preventing it from becoming static.

It is not necessary that everyone attend every workshop or activity but it is important to keep all vested parties informed. This displays transparency which builds trust between parties. It also means that parties have a greater overall understanding of the project at every stage.

In IT there is an abundance of communication and collaboration technologies. In fact, enterprise social media tools could be ideal for this kind of work.

5.    Study the details and the whole for clearer focus and perspective

By considering the problem at different scales (holistic company-wide impact down to specific details of project) and ‘zooming in and out’, a greater appreciation can be gained of where the two may conflict.

With this approach we find that communication between parties is more thorough and thereby more effective. But what does this mean in practice and how can you ‘zoom in and out’? One way is to use prototypes. Even simple paper prototypes can be used to explore detailed workings of a process or a new piece of software. Since the prototypes are simple, low fidelity, people don’t get caught up in discussing the aesthetics, and can instead consider the prototype in the context of the bigger picture. Business modelling in excel spreadsheets is another good example of prototyping.

6.    Produce a feasible plan for early validation

The primary goal of the Design Charrette process is to produce a feasible project plan. With all parties keeping feasibility in mind throughout the process, that process becomes more rigorous and parties pay greater attention to details that may be overlooked. They are constantly testing the ideas and any solution prototypes against the feasibility objective.

Feasibility requires that many of the previous processes are in place, especially those that keep all parties fully informed of key decision points. This applies in particular to parties concerned with finance, legal and compliance.

In my opinion, feasibility is not considered often enough at the beginning of IT projects. It is just assumed that anything is possible even within the time, budget, and resource constraints. But throughout this process, feasibility is constantly tested and we can make early go-no-go decisions rather than waste money building something that isn’t possible. Often we are only fooling ourselves.

Another advantage of this early focus on feasibility, is that there is time to consider other options and find a truly feasible solution. People are much more creative and sometimes it’s possible to reframe the problem in such a way that other solutions reveal themselves.

7.    Use design to achieve a shared vision and create holistic solutions

People discussing design ideas at Pathfinder workshopIn creating holistic solutions and a shared vision between parties, design is an invaluable asset. Diagramming problems and prototyping solutions are an effective means of illustrating the complexity of problems. It also allows for the development of novel solutions to help sort out disagreements between parties.

The key is to look at the problem from the end users’ point of view. By ‘walking in their shoes’ it’s easier to understand the real problems and to see what solutions will work.

In fact, this is the core concept at the center of another related and interesting field – Design Thinking. We’ll be exploring more of that in later blog posts.

I still don’t fully understand all the contributing factors to project failures in IT, but it appears that project management techniques have not kept pace with changes in the world we live in. Could this be a contributing factor to all the IT project failures? I think so.

As I look around in different fields, ranging from management science to economics, psychology to engineering, it seems to me there’s a lot we can learn about project management. There are techniques which work elsewhere, so why not adapt and adopt them? If fact at Daysha we’ve adopted many of the ‘Design Charrette’ techniques into our ‘Pathfinder’ process. You can find out more by downloading the white paper.

What do you think? Please let us know in the comments section below.

We plan to write some more articles on this topic and will discuss other techniques we can borrow from various fields in the near future.



  • Mark Stokell /

    My first thoughts when reading this post were “OK, what do we mean by project success?” If the success is taken as the inverse of failure then the regularly cited bench marks are the Standish reports, which constantly claim x% of IT projects fail (where x>>50%). Unfortunately, these reports, and their regular citation, contribute to the general impression that IT projects tend to fail. I tend to disagree with this assessment in spite of the obvious spectacular failures reported in the news (anyone remember PULSE?). Of course, I have little evidence to support my view other than that derived from my exposure to a limited project sample size. However, I do question the evidence to support the Standish report since it is never made public. Furthermore, their definition of success is narrowly confined to cost, time and meeting the original requirements. Important as these factors are I prefer the alternate definition of success: providing value and meeting (or exceeding) stakeholder expectations.

    I can see how these charrettes could significantly contribute to managing stakeholder expectations by comprehensive and inclusive involvement of all stakeholders. throughout the project. When considering current Daysha projects I can see how our requirements management and agile development processes mirror closely most of the NCI core strategies. This may go someway to explain our successes. However, I do agree that more of an upfront focus on feasibility would improve results further. I will consider how to improve feasibility assessment in upcoming projects.

  • Thanks Mark.

    You should check out the Catalogue of Catastrophe (http://calleam.com/WTPF/?page_id=3). I only recently found this myself. But certainly plenty of stories of project failures there.


Leave a Reply

Your email address will not be published.

mautic is open source marketing automation