Skip to main content

Tag: Leadership

A Question of Credibility: Why are Project Managers Afraid to Stop Projects?

In a recent study, the Accept Corporation and the Association for International Product Marketing and Management (AIPMM) found that more than 60% of executives say they struggle making kill/go decisions.[1] For some reason there is a tendency to continue projects and activities even when most people involved realize it’s not an optimal use of their time. Organizations generate a cultural momentum that, like a battleship, won’t turn easily or quickly even when the product team is aware of the issues. What causes this culture to develop? Are poorly aligned project incentives causing a proliferation of this behavior?

 Let’s look at some additional data to help shed light on this issue. In another recent study, The Study of Product Team Performance, 2012, [2] Actuation Consulting and Enterprise Agility found that:

  • Only 33% of product teams have daily priorities that are “strongly aligned” with the organization’s business strategies
  • Only 12% of respondents report on-time, on-scope, on-budget performance
  • Only 28% of respondents report “hit or miss” or “miss more than we hit” performance

This study also discovered that critical gaps exist in many organizations. These organizations lacked elements such as a multi-year product strategy and product portfolio management. 

From these findings, one could infer that most product development teams are working on projects that are not strongly aligned with their organizational strategy and have a strong likelihood to miss expectations. Can part of the reason be that teams are working hard to deliver projects but do not truly understand the nature of those expectations?

So often, after being assigned to a project, project managers try to run before they walk. This is especially common when the project is already in progress. You can quickly get caught up in the momentum of work and forget to question whether the work is justified. If this is truly the case, shouldn’t more projects be stopped? Aren’t project managers in the best position to go against this grain and make the recommendation to stop a project even when it’s not the most popular decision? Maybe the question should be: Would a project manager be afraid to stop a bad project even if it was the “right” thing to do but it meant losing his/her job?

What About the Project Management Code of Ethics?

It’s well documented that otherwise ethical individuals can be enticed to “bend the rules” because of poorly structured incentives. We’ve all probably seen some form of this behavior playing out in our organizations and product development projects. Whether it’s the business unit head who pushes an inadequately prepared team to reach a project go-live date in the interest of receiving a very large bonus, or a product manager trying to meet a roadmap item date but only delivering 50% of the customer’s requirements because incentives were linked to the delivery date and not the scope. Most of the time, this behavior is not meant to be malicious, but let’s face it, poorly aligned priorities linked to financial rewards can encourage individualist behavior in even the most ethical person. I honestly don’t think project managers are any more or less susceptible than any other profession to this type of behavior.

However, as a credentialed project manager, our behavioral conduct is governed by our Code of Ethics and Professional Conduct. Our code should provide us the clarity and direction we need when situations get confusing or conflicted — and projects need to be stopped. Let’s look deeper into our project management code for guidance.

Chapter four, Fairness, specifically states the following: “Fairness is our duty to make decisions and act impartially and objectively. Our conduct must be free from competing self interest, prejudice, and favoritism.

4.2.2 We constantly reexamine our impartiality and objectivity, taking corrective action as appropriate.

Comment: Research with practitioners indicated that the subject of conflicts of interest is one of the most challenging faced by our profession. One of the biggest problems practitioners report is not recognizing when we have conflicted loyalties and recognizing when we’re inadvertently placing ourselves or others in a conflict-of-interest situation. We as practitioners must proactively search for potential conflicts and help each other by highlighting each other’s potential conflicts of interest and insisting that they be resolved.[3]

And Chapter five, Honesty, states that:

“5.2.3 We provide accurate information in a timely manner.

Comment: An implication of these provisions is that we take appropriate steps to ensure that the information we’re basing our decisions upon or providing to others is accurate, reliable, and timely. This includes having the courage to share bad news even when it may be poorly received. Also, when outcomes are negative, we avoid burying information or shifting blame to others. When outcomes are positive, we avoid taking credit for the achievements of others. These provisions reinforce our commitment to be both honest and responsible.[4]

One could argue that our code doesn’t explicitly say “stop a project when it is bad” or that in certain cases the code is too aspirational — a topic for another day. But clearly it’s in our code of ethics that we, as project managers, need to make these tough recommendations to our stakeholders. So, why aren’t more projects being stopped?

What criteria do project managers use to determine if the project is off the rails with no sign of recovery? What happens if the project delivery is sound but the overall product strategy is flawed? Is it the job of the project manager to stop the organization from making this investment mistake even if he or she can deliver the project on time, scope, and budget?

If the reason that the project is “bad” can be attributed to tangible areas where the project will not meet stakeholder requirements (e.g., cost, time, scope), then it is the responsibility of the project manager to alert the sponsors so that the scope/requirements can be changed or the project cancelled. This, in fact, is one of the reasons you’re hired into the role of project manager.

However, in the case of a sub-optimal product strategy, some may interpret our loyalty mentioned in our code of ethics as loyalty to the project and the project charter, not necessarily to the common good of the organization. Some might argue that a great strategy executed poorly will almost certainly lead to failure; whereas a poor strategy, executed properly will likely have some measure of success. Once a project has been commissioned, the project manager’s focus is to execute according to the project charter. Presumably the sponsors (organizational management) are aware of strategic alternatives and, for better or worse, have chosen the project you’re working on. The current mantra is to accept this charter and execute it to the best of your ability.

As a project manager, you should be brutally honest when the viability of a project is in question, even if the concerns are regarding the product strategy. The reasons for this are important. For example, if the project no longer aligns with the strategic objectives of the organization, continuation will lead to wasted financial and human resources thereby undermining the organization’s credibility in the market. In this case, look for alternatives that could leverage the investment already made and provide value through a different, better-aligned project initiative.

So How Do You Define Success?

When creating, developing, and delivering a product to the market, we seek to maximize its value. In product development projects, the project manager typically collaborates with the product manager to construct detailed statements (success criteria) that are clear and measurable, focused around the areas of scope, schedule, and cost. Then, during the course of the project, the project manager forces the product manager to make decisions and tradeoffs against the three, but based on what? Does the product manager really understand what they’re being asked to trade-off against? The answer should be value.

Project Managers need to adjust their perspective around scope, schedule, and cost and relate it back to what the overall value is of the project. When you make this adjustment you realize that the balance of scope, schedule, and cost is more of an equation based on deriving value. I call this the project management value equation. It’s designed to give context to “scope, schedule, and cost,” ensuring that you’re weighing all that you do against the overall value of the project and keeping your product manager and product team focused on the prize. Said another way, it’s an equation meant to quantify and assess the value of a project and identify — if value has been decreased — whether the project should be stopped. The equation is (working model identified in book):

Value = Scope ÷ (Schedule + Cost)

By understanding this concept, you bring more depth and meaning to what you really need your product manager to trade off against. By assigning a value to each of your success criterion, you in essence are quantifying the value of the project. Remember, good project managers know that project success is not whether it’s delivered on time and within budget, but whether it delivers value and meets the defined success criteria.

Our project success criteria should then be evaluated using our code of ethics. Ask yourself, “are the intentions of the project feasible and ethical?” “Am I willing to act in an ethical way, to complete the project — even if completion means stopping it?” It’s likely that the project sponsor views this recommendation as a personal attack and the result turns out to be a career-ending move. In a tough economy, stopping a project becomes an extremely difficult decision. However, I still hold the position that, based on our code of ethics, the answer to the question…should a project manager stop a project even if it means losing their job…should be YES! When managing a product development project, our Code of Ethics is the backbone to our credibility — and sacrificing our credibility should never be an option.

Don’t forget to leave your comments below.


 

[1] Accept Corporation and Association of International Product Marketing and Management (AIPMM). PPM is Dead. Long Live Portfolio: Q2-2011 Study – Portfolio Management Priorities. June, 2011. Retrieved from accept360.com.

[2] The Study of Product Team Performance, 2012, Actuation Consulting and Enterprise Agility, March 2012

[3] PMI Code of Ethics and Professional Conduct ©2012 Project Management Institute, Inc

[4] PMI Code of Ethics and Professional Conduct ©2012 Project Management Institute, Inc


About the Author:

 Steven Starke is the author of S.T.O.P. – The Project Management Survival Plan. He is currently the VP of Program Management for Thomson Reuters and working with Actuation Consulting on training material focused on product team collaboration. Steve has held leadership positions in Program Management, Product Management, Systems Engineering, Product R&D, and Global IT and has run full-fledged PMOs. His industry experience ranges from consumer products and medical devices to global IT Infrastructure, healthcare analytics, and software development.

Tension at the Workplace: Gen X vs. Gen Y

To all project managers, quick! Pop Quiz!

a)      Did LOL ever mean “lots of love” to you?
b)      Do you remember a time before (or during) the Walkman?
c)       Was there ever a point in your life when perming was all the rage?
d)      In your heart, will Pluto always be a planet?

You probably realized by now this isn’t a real quiz. Nor is it a sadistic exercise to make you feel old. But what it should do is show that times have changed—and the workforce has changed with it. As each passing year increasingly necessitates cross-generational interaction, there is bound to be some cultural clashes along the way.

 The Princeton dictionary defines culture as “the attitudes and behavior that are characteristic of a particular social group or organization”. In this light, working with someone from a different culture doesn’t always mean working with someone of a different nationality. Cultural differences can boil down to your age.

This might explain why so much tension arises between the Baby Boomer, Generation X and Generation Y cultural groups. That’s right…cultural groups. Each of these generations respects a unique set of values and ideologies. These ideals can begin to conflict if not clearly communicated and understood within the team. So when cross-generational frustrations emerge at the workplace—ask yourself: Is this an issue of cross-cultural miscommunication?

Cross-cultural miscommunication between generations can occur almost automatically. Why wouldn’t it? It is very easy to assume that a co-worker who shares commonalities in language, nationality or education may also share similar outlooks in relation to work ethics, ideas of job satisfaction, motivational incentives and so on. But this is not the case.

For instance, while Generation X workers may find satisfaction in job stability, career growth and financial gain, Generation Y workers often find value in a proper work-life balance and the overall emotional fulfillment of the work. To put it crudely: if it ain’t fun, it ain’t done.

But don’t get it wrong. Generation Y workers will work hard—except their approach to work is what differs from previous generations. A Generation Y worker may even leave a job if it does not offer flexible or negotiable hours. The logic being: why work 8 to 9 hours a day if the work can be successfully delivered by noon? Such thinking patterns should not be interpreted, rather mis-interpreted, as lazy or self-centred by co-workers and leaders from previous generations. It’s just different.

Different isn’t bad. It is important for project managers to recognize the great potential Generation Y workers can bring to the workplace. The Gen Y worker’s love of technology, social media, remote working and willingness to prioritize work over salary (as long as the work is fulfilling) makes him or her an ideal candidate for the virtual work environment. However, if a project manager’s mindset still dwells in past managerial styles and expectation, it is possible that such talented people could slip right through the company’s fingers (and perhaps, land right into the hands of another, more flexible organization).

To understand and adapt to the new workforce, the most important aspect is to be open. Try to understand the worker as a person—as an individual. Perhaps the Gen Y team member wants to take an extended amount of time off, to travel the world, do charity work, or spend time with his or her aging parents. A project manager willing to adapt to such requests will not only augment trust, but also enrich the work experience for the employee, to make it exactly that…an experience, and not just “work”. In return, the Gen Y worker may start to adapt to certain traditional managerial styles out of mutual respect. At the end of the day, tasks are completed and both sides of the team are happy.

So as Bob Dylan would say (a name familiar across all generations!), “Times they are a Changing”…and perhaps our outlooks in the workplace should as well!

Don’t forget to add your comments below.


Claire Sookman is the driving force behind Virtual Team Builders, Claire brings to the table over a decade’s worth of corporate and public sector training experience, working with over 4,500 managers in the past three years. Specializing in virtual team building and communication strategies, Virtual Team Builders provides training that enables global teams to work more efficiently.

Selling Project Managers on Consistent Project Practices

Congratulations – you’ve convinced your senior leadership that implementing a consistent approach to project management is a key step towards realizing your company’s strategic vision! 

Once your initial euphoria evaporates, you’ll come to realize that you’ve only won the first battle in a long campaign – now you have to win the hearts & minds of the project managers.  This can be quite a challenge as the project managers will likely experience the greatest change to their normal routine.

This concern feels counter-intuitive – project managers should be opponents of entropy and surely there is no better method of bringing order to organizational chaos than by instituting consistent practices?  This assumption ignores a few basic truths:

  1. Project managers are usually overworked and their focus is usually on delivering their projects successfully under tight constraints.
  2. Process change (regardless of the benefits) usually reduces productivity for a short period of time until the change is fully assimilated.  The rare exception to this is if the benefit of the change will immediately offset the effort lost in learning and adopting the new practices.
  3. Even if the two preceding points don’t apply, most experienced project managers have honed their own tools and techniques over a period of time and might be hesitant about adopting new practices.

As with most “soft” change management challenges, there is no silver bullet, so a combination of the following techniques should help.

  1. Engage – no one wants to adopt a change that they haven’t had input into, so identify your most vocal or influential project managers and involve them in the definition of the new practices.
  2. Take a lean approach – Change for change sake is just going to increase the likelihood of resistance so make sure someone on your team is asking the question “Why do we need to make this specific change”?
  3. Leverage the Code – Members of PMI are required to adhere to the Code of Ethics.  The following excerpt from one of the standards of conduct aligns well with the benefits of consistent practice: “We accept accountability for any issues resulting from our errors or omissions and any resulting consequences.”  A lack of consistent practice increase the potential of project issues if a transition in project managers occurs.
  4. Evaluate – whether or not you have formal reporting responsibility over the project managers, try to build compliance with the procedural changes into their evaluation objectives, and incent them to champion the changes through visible recognition.
  5. Shift the workload – for the project managers working on the most challenging or large-scale projects, identify staff (or coop students) that are aspiring to project management roles and attempt to recruit them to assist these project managers as project coordinators.  The project managers will likely appreciate the ability to offload project administration activities to the project coordinators, and you’ll benefit by having the “next generation” of project managers aligned with your new organizational standards. 

If increasing project management consistency feels like herding cats, consider these practices as the change management equivalent of catnip!

Don’t forget to leave your comments below!

Where’s the Loyalty? How to Get The Most Out of Your Team Even in the Most Trying Times

Lack of loyalty is a serious problem in organizations everywhere today.

No longer do people join a company and devote the rest of their working lives to it.   Companies are, of course, not exactly known for offering up thirty or forty years of employment, a gold watch and pension plan.

Times have changed.  Businesses appear and disappear at a dizzying pace. So do the jobs they offer. People no longer expect to spend their entire career with the same company.

Organizations preoccupied with short-term, bottom line thinking often view their employees as little more than resources to be hired, fired, and manipulated as the need arises.

Both sides pay a price for this lack of loyalty. Workers are naturally less happy on the job when they sense little or no loyalty from their employer. I agree with Carmine Coyote about how the negative impacts on productivity are truly alarming:

  • People expect to be continually under threat of layoff, so they keep their resumes permanently on the market, changing jobs without concern for anything save their own short-term advantage.
  • Because they see executives cheerfully raiding the corporate coffers to enrich themselves, any natural unwillingness to engage in cheating or manipulating rules to put extra money in their own pockets is lessened.
  • Top level emphasis on quick, short-term returns (especially to themselves), permeates the organization as a whole, leading to everyone focusing on what will give them the biggest, quickest return—even if that means elbowing colleagues out of the way, playing the dirty politics, or hyping resumes to leverage a quick move somewhere else that is paying a few bucks more.
  • Loyalty to colleagues can turn into an us-versus-them attitude toward those higher up.
  • Worst of all, people feel devalued and see their work as less and less worthwhile. This creates emotional and psychological stresses and problems that go beyond the workplace and may last for some time.

What can you do to avoid this terrifying outcome?   Learn from others.

A century ago, Ernest Shackleton was one of the most renowned explorers of his time. He was a member of Captain Randolph Scott’s Discovery Expedition to the Antarctic in 1901–04 and led the Nimrod Expedition to the Antarctic in 1907–09, when he and three companions marched farther south than any human had ventured before. He was knighted by the king of England for that effort.

Today, however, Shackleton is best known for a failed mission. In January 1915,  while trying to be the first to journey across the Antarctica, he and his men aboard the Endurance were trapped in pack ice in the Weddell Sea and forced to abandon the ship. They floated on icebergs and paddled three small lifeboats to reach a remote, deserted island. From there, Shackleton and five men embarked in one of the lifeboats on an eight-hundred-mile voyage through some of the planet’s stormiest waters, landing more than two weeks later at South Georgia Island in the South Atlantic. After a rest, Shackleton and two of his men hiked and climbed across treacherous mountains to a whaling station, where Shackleton procured a ship and sailed to rescue his comrades. Every member of the twenty-eight-man crew returned home safely.

Margot Morrell and Stephanie Capprell, in their book Shackleton’s Way, list eight principles Shackleton applied to forge unity and loyalty among his team. As a leader, Shackleton was ahead of his time. His principles are just as important in today’s modern workplace as they were in the Antarctic a hundred years ago:

  1. Take the time to observe before acting, especially if you are new to the scene. All changes should be aimed at improvements. Don’t make changes just for the sake of leaving your mark.
  2. Always keep the door open to your staff members, and be generous with information that affects them. Well-informed employees are more eager and better prepared to participate.
  3. Establish order and routine on the job so all workers know where they stand and what is expected of them. The discipline makes the staff feel they’re in capable hands.
  4. Break down traditional hierarchies and cliques by training workers to do a number of jobs, from the menial to the challenging.
  5. Where possible, have employees work together on certain tasks. It builds trust and respect and even friendship.
  6. Be fair and impartial in meting out compensations, workloads, and punishments. Imbalances make everyone feel uncomfortable, even the favored.
  7. Lead by example. Chip in sometimes to help with the work you’re having others do. It gives you the opportunity to set a high standard and shows your respect for the job.
  8. Have regular gatherings to build esprit de corps. These could be informal lunches that allow workers to speak freely outside the office. Or they could be special holiday or anniversary celebrations that let employees relate to each other as people rather than only as colleagues.

If you demonstrate a strong measure of loyalty to your team, you’ll find that same measure of loyalty being returned to you. In these trying times – inspiring loyalty will help you get the most out of your team and lay the foundation for lasting success.

Don’t forget to leave your comments below.


Jeremy Kingsley is a professional speaker, author, and the President of OneLife Leadership. Since 1995 he has spoken to over 500,000 people at live events around the world. He has given over 2000 keynote speeches and his messages have reached millions through radio, television, and the internet.  Jeremy holds bachelors and masters degrees from Columbia International University. He is the author of four books: Inspired People Produce Results – Leading Generation Me (2013), Getting Back Up When Life Knocks You Down (2011), Be Last – Descending to Greatness (2008), One Step Closer – to a life worth living (2004).

Jeremy lives in Columbia, South Carolina with his wife and two sons.

Project Management Best Practices: Laying the Foundation

Bricklayer_33147456_XSManaging software projects is difficult under the best circumstances. The project manager must balance competing stakeholder interests against the constraints of limited resources and time, ever-changing technologies, and challenging demands from high-pressure people. Project management is a juggling act, with too many balls in the air at once.

Unfortunately, many new project managers receive little training in how to do the job. Anyone can learn to draw a Gantt chart, but effective project managers also rely on the savvy that comes from experience. Learning survival tips from people who’ve already done their tours of duty in the project management trenches can save you from learning such lessons the hard way.

This four-part series introduces twenty-one valuable practices that can help both rookie and veteran project managers do a better job. Perhaps these articles, which are adapted from my book Practical Project Initiation: A Handbook with Tools (Microsoft Press, 2007), can help you avoid some project pain.

The practices are organized into five categories:

  1. Laying the foundation
  2. Planning the project
  3. Estimating the work
  4. Tracking your progress
  5. Learning for the future

When initiating a new project, study this list of practices to see which ones would be valuable contributors to that project. Build the corresponding activities into your thinking and plans. Recognize, though, none of these practices will be silver bullets for your project management problems. Also, remember that even “best” practices are situational. They need to be selectively and thoughtfully applied only where they will add value to the project.

Practice #1: Define project success criteria.
At the beginning of the project, make sure the stakeholders share a common understanding of how they will determine whether this project is successful. Too often, meeting a predetermined schedule is the only apparent success factor, but there are certainly others. Begin by identifying your stakeholders and their interests and expectations. Next, define some clear and measurable business goals.

Some examples are:

  • Increasing market share by a certain amount by a particular date.
  • Reaching a specified sales volume or revenue.
  • Achieving certain customer satisfaction measures.
  • Saving money by retiring a high-maintenance legacy system.
  • Achieving a particular transaction processing volume and correctness.

These business goals should imply specific project success criteria, which again should be measurable and trackable. These goals could include achieving schedule and budget targets, delivering committed functionality that satisfies acceptance tests, complying with industry standards or government regulations, or achieving specific technology milestones. The business objectives define the overarching goal. It doesn’t matter if you deliver to the specification on schedule and budget if those factors don’t clearly align with business success.

Not all of these defined success criteria can be your top priority. You’ll have to make some thoughtful tradeoff decisions to be sure that you satisfy your most important priorities. If you don’t define clear priorities for success, team members can work at cross-purposes, which leads to frustration, stress, and reduced effectiveness. Chapter 4 of Practical Project Initiation presents a tutorial on defining project success criteria.

 Practice #2: Identify project drivers, constraints, and degrees of freedom.
Every project must balance its functionality, staffing, budget, schedule, and quality objectives. Define each of these five project dimensions as either a constraint within which you must operate, a driver strongly aligned with project success, or a degree of freedom you can adjust within some stated bounds. I explain this idea more fully in my book Creating a Software Engineering Culture (Dorset House, 1996).

I’m afraid I have bad news: not all factors can be constraints, and not all can be drivers. The project manager must have some flexibility to react to schedule slips, demands for more functionality, staff turnover, and other realities.

I once heard a senior manager and a project leader debate how long it would take to deliver a planned new large software system. The project leader’s top-of-the-head guess was four times as long as the senior manager’s stated goal of six months. The project leader’s response to the senior manager’s pressure for the much shorter schedule was simply, “Okay.”

A better response would have been to negotiate a realistic outcome through a dialogue:

  • How critical is the six-month goal? Does something drastic happen if we don’t deliver in six months (schedule is a constraint), or is that just a desirable target date (schedule is a driver)?
  • If the six months is a firm constraint, what subset of the requested functionality do you absolutely need delivered by then? (Features are a degree of freedom.)
  • Can I get more people to work on it? (Staff is a degree of freedom.)
  • Do you care how well it works? (Quality is a degree of freedom.)
  • Can I get more funding to outsource part of the project work? (Cost is a degree of freedom.)

While teaching a project management course once, a student insisted that all five dimensions were constraints on her project. She had a defined feature set that had to be delivered with zero defects by a specific date by a fixed team size working on a fixed budget. The likely outcome? She will most likely fail. An overconstrained project has no way to deal with requirement changes, staff turnover or illness, risks that materialize, or any other unexpected occurrences.

Practice #3: Define product release criteria.
Early in the project, decide what criteria will indicate whether the product is ready for release. Some examples of possible release criteria are:

  • There are no open high-priority defects.
  • The number of open defects has decreased for X weeks, and the estimated number of residual defects is acceptable.
  • Performance goals are achieved on all target platforms.
  • Specific required functionality is fully operational.
  • Quantitative reliability goals are satisfied.
  • X% of system tests have been passed.
  • Specified legal, contractual, or regulatory goals are met.
  • Customer acceptance criteria are satisfied.

Whatever criteria you choose should be realistic, objectively measurable, documented, and aligned with what “quality” means to your customers. Decide early on how you will tell when you’re done, track progress toward your goals, and stick to your guns if confronted with pressure to ship before the product is ready for prime time. See Chapter 5 of Practical Project Initiation for more about defining product release criteria.

Practice #4: Negotiate achievable commitments.
Despite pressure to promise the impossible, never make a commitment you know you can’t keep. Engage in good-faith negotiations with customers, managers, and team members to agree on goals that are realistically achievable. Negotiation is required whenever there’s a gap between the schedule or functionality the key project stakeholders demand and your best prediction of the future as embodied in project estimates.

Principled negotiation involves four precepts, as described in Getting to Yes by Roger Fisher, William Ury, and Bruce Patton (Penguin USA, 1991):

  1. Separate the people from the problem.
  2. Focus on interests, not positions.
  3. Invent options for mutual gain.
  4. Insist on using objective criteria.

Any data you have from previous projects will strengthen your negotiating position, especially because the person with whom you’re negotiating likely has no data at all. However, there’s no real defense against truly unreasonable people.

Plan to renegotiate commitments when project realities (such as staff, budget, or deadlines) change, unanticipated problems arise, risks materialize, or new requirements are added. No one likes to have to modify his commitments. But if the reality is that the initial commitments won’t be achieved, let’s not pretend that they will right up until the moment of disappointing truth. I discuss the importance of negotiating achievable commitments in Chapter 9 of Practical Project Initiation.

These four practices can help you get your project off to a solid start, with a clear idea of where you’re headed. In Part 2 of this series we’ll take a look at eleven best practices for planning the project.

Don’t forget to leave your comments below.


Karl Wiegers is Principal Consultant at Process Impact, www.ProcessImpact.com. His interests include requirements engineering, project management, peer reviews, and process improvement. His most recent book is a memoir of life lessons titled Pearls from Sand: How Small Encounters Lead to Powerful Lessons.