Tag: Project Management

42, The Douglas Adams IT Project Management Experience

Written by Donato Piccinno on January 10, 2018. Posted in Articles. 3 Comments on 42, The Douglas Adams IT Project Management Experience

According to Douglas Adams the famous author of The Hitch Hikers Guide to the Galaxy 42 is the answer to everything.

The story goes like this. The most advanced race of beings in the whole universe decide to build a super computer to answer the ultimate question. They wait in anticipation for the greatest technical marvel the universe has ever seen to provide the answer. After the wait is over the answer is 42. The answer is so clever the most advanced beings in the universe cannot understand it. Rendering their creation absolutely useless. The story is a cautionary fable in the faith we place in technology and hyperspecialism to provide the answers to make the way we want to do things easier. Douglas Adams is more than an author. He is adept at conveying the outcomes when the human condition meets technology and process. The unintended consequences when humans do the human thing. Which is to do the completely unpredictable things the technology and process does not expects us to do. How very dare they! The audacity of it all! Douglas Adams quotes and thoughts can all be observed in action at the point IT solutions are conceived in the word of Enterprise Architecture then project managed into use by the real world. It’s the point where technology, human nature and process meet. Anticipating these outcomes well and things go well. A lack of anticipation normally results in unintended consequences. Where IT project delivery is concerned the same old story statistics on IT project performance from Standish and Gartner show a Douglas Adams observation in action.

Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so.

We are classically trained to formulate the delivery of IT solutions with our scientific management head on. The ghost of Taylorism permeates every single way of working while delivering an IT project. The consequences are plain to see in the repertoire of Douglas Adams quotes. Missed deadlines, services that don’t meet needs, waste, cyber crime, disillusioned workforce and technology that fails to perform the moment it is exposed to the real world.

A common mistake that people make when trying to design something completely fool proof is to underestimate the ingenuity of complete fools.

I was actually inspired to write this piece following a meeting about rolling out a few laptops and phones. The experience was most humbling and ego destroying. I came away from that meeting kicking myself for falling for the illusion of control scientific management and technology can instil in us. For the meeting we’d come up with this text book rollout process for network, printing, HR, pcs, laptops and phones. Any methodical process type person would not fault it. But it had two fundamental flaws. For the process to work and give the final user the experience they were looking for everyone in the process had to follow the process. The key principle was 20 days prior to the IT solution going live the process needed to know the name of the employee. But in the real world a person could be employed on the day they needed the solution. Without the IT solution that employee would be sitting around for several days as a new starter request made its way through the process. The 2nd fundamental probably caused the team to miss the 1st fundamental flaw. The process was designed by experts who had no idea what it was like to be the user on the day they needed the IT solution. We knew what they needed from a functionality perspective but had no idea what it was like to be the user. So who were the ingenious fools in the Douglas Adams quote? The end user not following the process? Or the team that designed the process. IT project plans consist of activities from many different domains. Our plans are full of specialists i.e. legal, procurement, engineers, Infosec, HR, developers, architects, user managers, finance and the ITIL brigade. All insisting on something done in a certain way. I’m sure their motives are ulterior and it is always for the good of the company. But there is an inconvenient truth my comrades can fail to grasp. Unless experts design solutions or process from the point of view of the end user what is being insisted on is as much use as a chocolate teapot.

He was a dreamer, a thinker, a speculative philosopher… or, as his wife would have it, an idiot.

Again it’s the human condition and nature at work. As IT project delivery experts we like to think we are right even when we have zero experience in what the end user experiences. That makes anyone who thinks like that an idiot. The way around being an idiot during delivery of an IT project is to constantly check for experience shortfall within the team designing the process. A lack of experience in the experience of the end user in their operational environment is the experience shortfall. Secondly, involve people who have done what you are trying to do. Fail fast by rehearsing implementation scenarios early and often. Particularly, where the rollout environment has the following context:

Accessing the solution from or connecting to a heterogeneous network
Rollout sites are remote
Users are not tech savy
There is an inter generational gap between the project team and the end users

To give real service you must add something which cannot be bought or measured with money, and that is sincerity and integrity.

Advertisement
[widget id=”custom_html-68″]

Back to our user who has just been employed and walked in on the day of rollout. With my compliance and process adherence hat on I could say, ’Sorry we cannot give you a phone and laptop you need to do the job. Please liaise with your line manager.’ What if a whole organisations existence is about that particular type of user being empowered from day one. The beating heart at the heart of the house so to speak. The process compliance world tends to have a transactional relationship with the real world. As long as the real world behaves in a way that is a valid transaction. Everything is #peachy. If not, the tendency will be to try and get the real world to change. Which is fine until such a stance becomes dogmatic or a non-starter because the real world cannot be changed. An IT project delivered in that kind of culture is unlikely to perform on many fronts. Usability for ease of use and ease of deployment will suffer a dip in a performance. What if we rethink the project plan to rollout an IT solution based on principles or probity, sincerity and integrity? What if we view the user experience of receiving an IT solution as a customer experience? Would we end up with an outcome where on the day we say, ’Sorry we cannot give you a phone and laptop you need to do the job. Please liaise with your line manager to go through the process.’ No, a customer of the project would have their IT solution ready at the point the needed it.

Thinking of a rollout process from a perspective of customer experience management, probity, sincerity and integrity results in handovers of IT solutions where all user personas and real world circumstances get considered. Such thinking challenges the way IT solutions are designed to be accessed. For example, take cached credentials. Great from a security compliance point of view but as much use as a chocolate teapot in the rollout scenario below. With cached credentials the device has to be sent back to base.

Heterogeneous network
Remote sites
User details not known until the day they need the laptop or PC.

A prime example of the technical world not understanding the real world. Leaving the project wide open to the following outcome. Observed by Douglas Adams at the touch point between human nature, the human condition, technology and experts who lack understanding of the real world. The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at and repair.

Project Management Education: Cultivating Cognitive Readiness and Optimal Performance

Written by George Pitagorsky on January 9, 2018. Posted in Articles. 3 Comments on Project Management Education: Cultivating Cognitive Readiness and Optimal Performance

Many project managers are self-taught, often thrown into the water to sink or swim.

This article addresses the need for PM education to cultivate the cognitive readiness you, your team and your organization need to perform optimally.

The Need for Expertise

For the large number of small projects that are performed in organizations, ‘accidental’ project managers with intuitive skills may be OK. However, when it comes to larger, more complex and mission critical projects, project managers with significant project management (PM) knowledge, skills and experience are needed.

The Project Management Institute (PMI) identifies three dimensions of project management expertise:

Technical – the specific skills of scheduling, risk management, cost management, etc. and the use of project management tools that support these skills.
Strategic and Business Management – understanding organization structure and the impact of it on projects and projects on it, cost and benefits assessment from a business perspective, business strategy, etc.
Leadership – skills related to motivating and managing people, including communication, conflict management and relationship management skills

This has been a major step forward in the PM field, clearly recognizing that it is not sufficient to know how to construct a schedule or WBS to be an effective project manager.

Now, the field is recognizing Project Management education must go beyond the simple transfer of knowledge to the cultivation of the ability to integrate skills to manage in volatile, uncertain, complex and ambiguous (VUCA) situations.

Integrated technical skills, organizational awareness, mindfulness, communication skills, managing change, conflict and expectations, and the application of emotional and social intelligence are needed to ensure that qualified people manage projects in a way that contributes to a consistently high probability of success.

The PM Education Objective: Prepare for Optimal Performance

The key to effective PM education is remembering that the objective is to prepare people for optimal performance, measured by the degree to which project managers add business value and consistently satisfy stakeholder expectations.

Optimal does not mean perfect. It means continuously improving performance that is as good as it can be under prevailing conditions.

PM Education is essential to effective project performance. To be deficient in any PM skills, whether technical or not, increases the risk of project failure. For example, a person playing a PM role who has no knowledge of the use and importance of a WBS will be more likely to develop a task list that is incomplete and difficult to manage. A PM deficient in communication or decision-making skills risks developing poor relationships, causing confusion and making poor decisions. A PM deficient in mindfulness and emotional intelligence is likely to be reactive rather than responsive.

The State of PM Education

PM education is big business. The domain of technical PM education is filled with courses on every aspect of project management performance – task analysis, scheduling, procurement, critical chain and path, risk management, etc. Many of these courses are well done, with participants gaining knowledge that they can apply on the job or use to pass an exam.

When it comes to providing education regarding business management and strategy, the coverage is not as complete. Offerings in this domain tend to be theoretical. Though, they do raise awareness and provide frameworks to apply theory to specific organizations. Ideally, practical education in this area should be specific to the organizational environment.

Leadership courses abound – some are great, some OK and some terrible. For example, one young project manager shared that the course she took on handling difficult conversations left her frustrated because it did not address situations in which the other party was completely oblivious to anything but his own opinions and positions and was verbally abusive. The course assumed that everyone was rational and working toward a win-win outcome. The instructor had never actually worked in any complex project. For leadership courses to be effective they must be anchored in real world experience.

Many courses focus on specific subjects, often without putting the subject in the overall context of projects in organizations. They teach students how to do a risk register without dealing with the political, scheduling and budgeting issues that underlie risks.

Programs that integrate a full range of subjects into a comprehensive education program tailored to the specific culture of an organization are rare and often limited to fundamentals and certification training. Some of these comprehensive courses are nothing more than a string of individual modules on each topic that fail to address the interplay among the topics – for example the way communication and conflict management skills are used in the context of scheduling.

Comprehensive, Integrated PM Learning

No one learns a complex skill without applying it in real-world situations and getting feedback about performance. Integrated courses that center on case study’s and workshop simulations are needed. Though they are not enough.

Coaching and mentoring and opportunities to address questions and issues with subject matter experts and peers are necessary parts of education. This ongoing learning is far less prevalent than standalone courses that have little or no follow up to ensure that learning is applied and makes a difference in performance.

Advertisement
[widget id=”custom_html-68″]

A comprehensive PM education program is more than a traditional curriculum of courses. It must be fully integrated into the fabric of the organization and the individual’s personal practice. A full program consists of

Courses in various media, over time, with multiple levels of skill advancement
Integrated workshops
Self-paced opportunities to refresh knowledge
Coaching and mentoring
Regular Q&A sessions
Communities of practice
Lessons learned events
Feedback & Continuous improvement.

The program may be formal and provided by the organization. Whether that is the case or not, it is the individual’s responsibility to make sure he or she is continuously cultivating the readiness to perform.

Cognitive Readiness (CR)

The objective of PM education is to enable optimal performance. Optimal performance relies on cognitive readiness.

In the military “Cognitive readiness is the mental preparation (including skills, knowledge, abilities, motivations, and personal dispositions) an individual needs to establish and sustain competent performance in the complex and unpredictable environment of modern military operations.”¹Change “military operations” to “project operations” and we have a good working definition.

Cognitive readiness, is the readiness of individuals and teams to apply their skills and to explore their faults and deficiencies and make the effort to overcome them. Cognitive readiness implies the courage and candor to objectively assess performance and improve it as needed. It implies the resilience and the capacity to accept uncertainty and paradox. It is enabled by and enables a healthy perspective and the application of knowledge and experience.

Cognitive readiness (CR) is cultivated in an educational program that goes beyond traditional technical, business and leadership skills to include

Organizational awareness – Knowing the nature of people in organizations, particularly one’s own,
Mindfulness – The ability to step back and objectively observe
Emotional and social intelligence – The ability to effectively manage one’s emotions in the context of relationships
Wisdom – a perspective that recognizes that
- service is the ultimate motivation for leaders
- everything is impermanent in a continuous change process
- no one has complete control
- we are responsible for the results of what we say and do, and
- nothing is without imperfection

Wisdom, informed by mindfulness and education, leads to the personal dispositions (attitudes, beliefs, etc.) that promote optimal performance.

Learning and applying all that is not easy. Learning begins with awareness that, unless they are cognitively ready, individual practitioners are unlikely to be able to perform optimally. The performance of teams and the organizations will suffer along with individual careers.

Cognitive readiness and the cultivation of optimal performance should be a primary objective of any PM Education program. If your organization is not providing the right program, it is up to you to craft your own and to manage your own learning and development.

1 Morrison, John E. and J. D. Fletcher, Cognitive Readiness, Institute for Defense Analyses, 2002. Download at http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA417618 , p. I-3

OUTSIDE THE BOX Forum: When is Agile Required?

Written by Robert Wysocki on January 8, 2018. Posted in Articles. 4 Comments on OUTSIDE THE BOX Forum: When is Agile Required?

We’ve all read articles that talk about choosing between traditional approaches and agile approaches.

Traditional projects can use an agile approach but agile projects cannot use a traditional approach.

There are some projects where that choice is a valid concern. But there are projects where some type of agile approach is not an option. It is a requirement. These are projects where the goal and/or the solution are not clearly defined or understood. In such cases the discovery of the missing piece(s) must be imbedded in the work of the project and that can only be achieved through some form of iterative process. Each iteration is an attempt to learn or discover missing parts of the goal and/or solution. After some number of iterations the goal and solution will be clearly known. To avoid an agile approach some traditionalists might try to jury rig their favorite waterfall model but that thinking is seriously flawed.

So complexity and uncertainty are the factors that lead to the conclusion that some type of agile approach is needed. But agile is a journey not a destination. There are several different agile approaches. So how do we choose the one that is the best fit given the project characteristics? Let’s try to answer that question.

THE COMPLEX PROJECT LANDSCAPE

The most intuitive illustration of the situation is the four-quadrant landscape defined by the two project characteristics: goal and solution. Every project has a goal and a solution to achieve that goal. Complex projects lack some clarity of goal, solution, or both and are found in Quadrants 2, 3 or 4. All of them will require some type of agile model.

Figure 1: The Complex Project Landscape

Agile Models Ranked from Mostly Defined to Mostly Undefined

After 25 years of client engagements where all types of agile projects were planned and executed I have adopted a ranking from mostly defined to mostly undefined. You might also use least complex/most certain to most complex/least certain. This is not an objective ranking. There are at least a dozen models that could be included. I’ve only chosen five for this article to illustrate the point. Each is briefly discussed. For a more complete treatment see [Wysocki, 2013]. The ranking is quite subjective but based on my personal experiences in using the models. There are also variants of each of these that affect their application.

Prototyping

This is a tried and true approach couched in the language of the client. There are a variety of variations from iconic models to production models. Prototyping is a very robust tool with a long history of uses including even the most complex and uncertain of project situations. Those would be situations where the project manager is using prototypes to suggest a starting point for the client to get on board with the search for a solution. Prototyping is a tool that keeps the client in their comfort zone during that search. It is quick and simple. There are several software applications that can generate and modify prototypes in real time.

Advertisement
[widget id=”custom_html-68″]

Evolutionary Development Waterfall

The only reason for using this is that it keeps the development team in their comfort zone. Project teams that have a long history of using the Waterfall Model will often choose this as their first step towards an agile environment. Unfortunately that is probably the only reason for using it when the situation calls for an agile model. It is very inefficient and wasteful of resources and time.

Scrum

The agile project world is dominated by Scrum [Schwaber and Beedle, 2001]. It is a sound model that keeps the client in charge through the Product Owner. That is, if you have a properly skilled Product Owner. Of all the common development models Scrum is a customer-driven model. Scrum does not have a project manager but the role is subsumed primarily by the team of senior developers, which operates as a self-managed and self-directed team. Co-location of the team is a critical component. Scrum teams tend to be small (less than 10 members). The temptation is to equate Agile to Scrum. There are many agile models of which Scrum is the most popular but the complex project landscape is broad and deep and can validly support a much richer portfolio than just Scrum.

Dynamic Systems Development Method (DSDM)

This model is popular in the EU [Stapleton, 2003]. At any point during implementation it allows the team to return to any previous stage in the design, development and deployment of the solution. DSDM is what the Waterfall Model would look like in a zero gravity world.

Effective Complex Project Management (ECPM) Framework

This is the new kid on the block [Wysocki, 2014] and [Wysocki, 2016]. It isn’t a model in the sense of the above. Rather it is a framework (Figure 2) that embraces a portfolio of models and a decision process for choosing and adapting the best fit model from the portfolio.

Figure 2: The ECPM Framework

It can be used for any agile project but is most useful when so little is known about the goal and/or solution that choosing and adapting the best fit model is not much more than a coin toss. it offers a decision model to help in that choice. The major advantage of using the ECPM Framework is that is designed to include the meaningful involvement of the client. ECPM is also a significant step towards establishing a collaborative project environment. Scrum includes that involvement through the Product Owner. The other models do not have meaningful client involvement as a design feature.

PUTTING IT ALL TOGETHER

All of these models and others should be included in the organization’s portfolio and the best fit one chosen based on the project’s characteristics, the organizational environment and culture in which the project will be executed and the market conditions the prevail. The specific types of projects the organization encounters might suggest that other models be included as well as customized models the organization has developed for repeatable projects. Choosing the best fit model is a multi-criteria decision. Preferences and availabilities have a lot to do with the choice. For example, Scrum requires more senior level developers because the projects are self-managed and self-directed. In the absence of senior level developers Scrum would not be a good choice.

[Schwaber and Beedle, 2001] Schwaber, Ken and Mike Beedle, 2001. Agile Software Development with Scrum, Pearson.
[Stapleton, 2003] Stapleton, Jennifer, ed., 2003. DSDM: Business Focused Development, 2nd Edition, Pearson Education
[Wysocki, 2013] Wysocki, Robert K., 2013. Effective Project Management: Traditional, Agile, Extreme. 7th Edition, John Wiley & Sons.
[Wysocki, 2014] Wysocki, Robert K., 2014. Effective Complex Project Management: An Adaptive Agile Framework for Delivering Business Value, J. Ross Publishing
[Wysocki, 2016] Wysocki, Robert K. and Colin Bentley, 2016. Global Complex Project Management: An Integrated Adaptive Agile and PRINCE2 LEAN Framework for Achieving Success, J. Ross Publishing

Married with Children Volume 2: The Newlywed Game

Written by Michelle Green on January 2, 2018. Posted in Articles. 5 Comments on Married with Children Volume 2: The Newlywed Game

As stated in Volume 1 of our “Married with Children” series on communication tips and tricks to a positive Project Manager/Business Analyst relationship, nothing can positively or negatively affect a project team more than the PM/BA relationship.

In The Dating Game we concentrated on the first date, or the PM/BA Kickoff Meeting, where the foundational structure of the PM/BA team is laid.

Now you’ve said “I Do”, have your new house, or project, and you find yourself married and living together in newlywed bliss. That’s the beginning of the marriage where things are going smoothly and everyone is excided. This is the optimum time to establish regular communications with each other so you both can grow and positively affect your project. It’s time to play The Newlywed Game, or quite simply have a PM/BA One-On-One. This is the project equivalent of “honey how was your day?”. For an effective PM/BA One-On-One, follow this simple guide:

1. Schedule It

The PM/BA One-On-One should be a weekly meeting where you can provide project updates to each other. It’s not a formal project status report, nor should it require documentation other than any deliverables that may come out of it. Each of you bring different perspectives and have different type of relationships with the same project team members. You may attend meetings the other may not attend. This is your chance to keep each other informed. Keeping a scheduled cadence offers you the ability to groom your relationship and can even be something you look forward to in times of project stress. Schedule a recurring meeting to carry you through the entire project duration.

2. Review the Project Status

Quickly review the project plan to have a joint understanding of where the project is at the moment. Similar to a scrum meeting, but at the project level, just provide a short completed this week/doing next week/roadblocks update so you both have a handle on where you may need to course correct and how you can support each other if needed.

Advertisement
[widget id=”custom_html-68″]

3. Review the BA Workplan Status

In any good marriage we learn to speak in each other’s language if we want to gain joint understanding and get things done. Having a weekly communication meeting speaks heavy to the BA’s communication preferences, but can seem non-productive to a PM if not approached with a plan and direction. An effective BA work plan contains a personal Work Breakdown Schedule, and is the single greatest thing you can create as a BA for your PM. It’s speaks in the language of the PM, and gives them an understanding of your personal impacts to the project schedule. It can also help them understand your work estimates more clearly and provide clarity for a PM that may have an idea that BA work is mainly comprised of gathering requirements. This document can also help drill home early in the relationship all the different tasks associated with BA work. The BA Workplan should include items such as BA tasks by project phase, estimated hours for tasks with start and end dates, completion percentages, and associated stakeholders.

4. Provide Feedback

In “The Dating Game” we discussed creating a PM/BA Prenup or getting a handshake agreement on how to communicate issues, concerns, and provide mentoring or feedback to each other during the course of the project. The weekly PM/BA One-On-One is the perfect platform for following through on your agreements. This should be a safe place to go over anything each other has seen the other do, say or react to that could use some work On the flip side, highlight something that was awesome. Who better to mentor you than someone who sees you in action more than any one other individual on a project? Now don’t go crazy. You don’t have to be on the lookout for mentoring opportunities every week, or look for something to harp on…just state it if you see it and ask for advice if you need it.

The PM/BA One-On-One is your time to get project updates and feedback, but we are all human, and just as parents complain about their kids or their day at work, sometimes you may just use this meeting to complain to a sympathetic ear. As long as it’s not a habit that’s okay! It’s all part of relationship building. The important thing is that you meet and continue to groom and mature your partnership for the benefit of your project team or any future projects you may have together.

Be sure to look out for the next installment of the Married with Children series, The Happy Family – PM/BA Relationship Do’s.

Change is Difficult, but Change Management Can Mitigate the Pain

Written by Parvathi Iyer on January 2, 2018. Posted in Articles. 4 Comments on Change is Difficult, but Change Management Can Mitigate the Pain

Ah, the floppy disk. Does anybody even use it anymore?

On the face of it, nobody should be using floppy disks in the 21st Century. Surprisingly, however, parts of the aviation industry still rely on these disks to manage airplane software.

Because airplane software is still distributed via floppies, most older airplanes have these disk drives built in to read and load from the relics. Certain airplane software arrived in sets ranging from 21-48 disks, with a technician loading them one disk at a time on the airplane. This was an error-prone process, and technicians required many hours trying and retrying to get all 21 or so disks loaded without the system timing out. Yet, when it came to eliminating floppy disks and changing it to a quicker, faster way of loading software, the technician’s comment was often along the lines of, “come back in 10 months, I will be retiring. You can change what you want then.” One airline rep commented that they have a stash of floppy disks that would be “wasted” if they transitioned.

Back in the day, a company I worked for decided to put in a new Case Management System, the system to log and manage customer issues and complaints. As a larger computer hardware and software products company, the organization of after-sales customer support represented approximately half the company’s work. It also had an entire eco-system of applications, add-ons, reports, extracts or UDAs (User Developed Applications). The current case management system was something everybody liked to complain about. The main reason for the UDAs was cited as the lack of features and functionality. In fact, replacing it with a newer, user-friendly one was the No. 1 request in a company-wide survey. Still, when it came to replacing it, most users wanted the new system to be exactly like the old one, flaws and all.

The first example is a technology change. The second is an IT system change. The common denominator in both is change. Surprisingly, most technology or IT projects don’t focus on Change Management. The people factor is largely ignored. These projects are run with a small-ish core group of people, the subject matter experts who define the requirements for the project, largely ignoring the vast majority of the people impacted by the project. It’s not surprising, then, that most of the technology projects end up with huge scope creep, or have many issues during roll-out and are inevitably perceived as disasters by the people impacted, sometimes despite meeting all the project goals.

When it comes to work, we are creatures of habit and routine. Most of us take pride in what we do and want to be known for excelling in it. We don’t like it when somebody changes things on us. Change represents a lack of control in some ways, which is why we resist it.

Change works when people feel involved and that they are contributing to the process. It works when people have the time to adopt and internalize the change. As the Project Manager involved in both of the referenced projects, I’ll share a few project management tips that help with managing these changes:

Create the vision

Start with the end state and draw it. And I mean draw. A picture speaks a thousand words. Use this as your reference to communicate the goals, breakdown tasks, report progress. Most people like to see the end-state at the starting point. As the project progresses, people want to see where they are going and how the journey is connected to the end-state. Consistently using the end-state as a reference will reiterate your key messages and also lend credibility to the project.

Plan backwards

Break the end-state into achievable sub-parts or phases. Start with where you need to be and then think of what you need to do to get there. This helps people focus on what needs to be done rather than what is happening now, and also what can be done rather than that which cannot.

Don’t over plan

Be agile. Detail the phase in which you will be spending the most time. Add details to the later phases as you get closer to execution. The reason is three-fold: First, people get obsessed with dates and details and lose sight of the big picture. Second, too many details can cause you to lose the flexibility required to change your plan; Third, people remember dates and hold you to them – it’s easy to lose credibility when you are perceived to be missing deadlines.

Plan for a pilot, a prototype or a user experience focus group

If your project allows for it, start with a pilot. Or create a prototype. Start with a small group of users and monitor their experience. Incorporate the feedback in your plan or product. Agile projects lend themselves to an iterative way of development, where user feedback is incorporated in all stages of product development. However, user experience and feedback can be explicitly included as tasks/events in non-agile projects, if the project demands it.

Advertisement
[widget id=”custom_html-68″]

Communicate, communicate, communicate

Most companies have existing framework and cadence for communications, formal and informal. Find the internal team meetings, the forums, the newsletters, the user groups, the task forces, the internal conferences. Create a project website and update it regularly. Spread the word and then reiterate it again and again through the life of the project. Get feedback. Follow up on questions and comments. This gives people the opportunity to be involved and contribute. Too often the change is too large with very little time for people to adjust and adapt. Early and routine communications give people the opportunity to adjust.

Protect yourself

Yes, sometimes things get personal. Even the best project managers sometimes lose the fight with public opinion and perception. You can be vilified as a terrible Project Manager for the simplest of missteps, real or perceived. Recruit your management to provide air cover. You need an advocate or two who can speak on your behalf and defend you. Bolster your credibility by recruiting the folks with their own street credibility and engaging them in your cause. A few words from them can quiet the worst critic.

Don’t aim for perfection

Accept that you will make mistakes. Build the atmosphere for continuous improvement, for yourself, the project team and the project. Hold periodic reviews or lessons learned retrospectives and use these as opportunities for improvement.

To me every project represents change of some kind. It is important to understand the change and proactively plan to manage the change as part of the project planning.

Note on Change management:

Organizations embark on projects for various reasons: Adding new products, terminating product lines, creating new processes, introducing new technology, ID-ing new opportunities, addressing issues etc. Often, these initiatives require changes to existing processes, job roles, systems. This requires change in how the employees of an organization do their jobs. Ultimately, the success of an initiative depends on how successfully individual employees transition and adopt to the new changes. This is key for any initiative to deliver expected results. Change management should be part of project management. While project management ensures that the project delivers its intended solution, change management ensures that the solution is adopted and used effectively.