Running a Project is Sort of Like Raising a Baby – Sort of

I have a large family – and thankfully that family became a little larger three weeks ago today so this article topic seems appropriate.  It came to me earlier this week that running a project from start to finish is kind of like raising a baby from infant to adulthood.  Ok, it’s a stretch, but there are similarities.

It could be that this all came about in my mind as a result of several straight relatively sleepless nights.  Or maybe I am on to something.  Who knows?  But the more I thought about it the more I realized that there are some relative similarities.

Pregnancy = pre-engagement/sales

Think of all the work that goes into the pre-engagement portion of the project … basically the sales portion.  This is what happens before handoff of the project to the project manager.  So, Sales = 9 months of pregnancy.  Are you staying with me so far?  When handoff is ready to happen, you kind of know what you’re getting – or at least you think you do.  In reality, it may be close but there are lots of details that you really have no clue about and you have to dig deeper so you know what you’ve just gotten yourself into.

Delivery = kickoff

The actual delivery is somewhat like project kickoff.  It’s when you finally see some early details of the project up close … live and in person.  Just like you get some new and very key information from the customer you also get some initial information from the doctors and learn if there are any conditions of your baby that need immediate attention.

Infanthood/toddler = design

The infant and toddler stages = design, in my opinion.  Just as you’re designing the system to the requirements of the customer, you’re also training your infant/toddler what’s right and what’s wrong and hopefully molding them to meet yours and God’s requirements for a well-rounded individual.  And, just like designing to the customer’s requirements, it’s not very easy and it does often involve some re-work and change orders!

Read more »

Making Good Project Decisions – Part 1

Everything you do every day is a kind of decision: what time to wake up, what to eat for breakfast, and who to talk to first at work. We don’t often think of these as decisions because the consequences are so small, but we are always making choices. We all have our own natural judgments for which decisions in our lives demand more consideration, and the same kind of logic applies to project management decisions. Some choices, like hiring/firing employees or defining goals, will have ramifications that last for months or years. Because these decisions will have a longer and deeper impact, it makes sense to spend more time considering the choices and thinking through their different tradeoffs. Logically, smaller or less-important decisions deserve less energy.

So, the first part of decision-making is to determine the significance of the decision at hand. Much of the time, we do this instinctively; we respond to the issue and use our personal judgment. Am I confident that I can make a good decision on the spot, or do I need more time for this? It often takes only a few moments to sort this out. However, this is precisely where many of us run into trouble. Those instincts might be guided by the right or wrong factors. Without taking the time, at least now and then, to break it down and evaluate the pieces that lead to that judgment, we don’t really know what biases and assumptions might be driving our thinking (e.g., desiring a promotion or protecting a preferred feature).

With that in mind, here are some core questions to consider when evaluating a decision. This list can be used in the moment to help size up a specific decision, or as a way to re-evaluate your high-level criteria for sizing up decisions.

Read more »

Virtual Teams: Key Success Factors – Part 3

As we identified in Part 2 – seven key success factors for virtual teams are:

• Human resource policies
• Training and on-the-job education and development
• Standard organizational and team processes
• Use of electronic collaboration and communication technology
• Organizational culture
• Leadership support of virtual teams
• Team-leader and team-member competencies

In this Part 3, let’s look deeper at the final three of these: organizational culture, leadership support, and team competencies.

Organizational Culture

Organizational culture includes norms regarding the free flow of information, shared leadership, and cross-boundary collaboration. It helps to create organizational norms and values that focus on collaboration, respecting, and working with people from all cultures, keeping criticism constructive, and sharing information. The organization’s culture sets the standard for how virtual team members work together. An adaptive, technologically advanced, and nonhierarchical organization is more likely to succeed with virtual teams than is a highly structured, control-oriented organization.

Read more »

Final Thoughts on Requirement Prioritization

Your first priority in the requirement prioritization may be selling the stakeholders on the concept of prioritizing requirements before design start.  This isn’t an easy task.  As we discussed, a customer stakeholder is likely to react with the notion that you’re actually trying to eliminate requirements.  You have to convince them that this is not the case.

Once the stakeholders agree to prioritizing requirements, you will guide the stakeholders through the prioritization process.  Then, you will incorporate the results into the project or the product development schedules and budgets.  You must enforce the priorities throughout the development process.

As development progresses, you will identify situations that trigger use of the priorities.  These situations may include: impending resource shortages, changes in external constraints or expectations, and conflicts.  You must ensure that the priorities rule the outcome.

Requirement prioritization early in development helps a manager control project risk and change.  Knowing requirement priorities focuses a product or project development team and guides intelligent choices for phasing in product features over time.  It prevents the “bailing” that so often occurs just before delivery, in which partially implemented requirements are thrown overboard in a frantic effort to save dwindling resources for finishing the critical components.  Above all, it’s one more communication channel between customers and developers.

Read more »

Getting Stakeholders Onboard with Requirements Prioritization

Defining requirements is all about communication between customers, project managers, and developers.  Requirement priorities improve communications between these main parties.  The payoff is not obvious to everyone, however, and you will probably have to sell the concept of prioritization to your stakeholders.

Customer resistance

An external customer is probably the hardest stakeholder of all to sell on the concept of prioritization.  Customers have difficulty with the concept.  Requirement prioritization on the surface may appear to the customer to be of primary benefit to the developer, thus leaving you with a tough selling job on prioritization to the customer.  Many customers initially view a request to prioritize requirements as a backdoor way to reduce the number of requirements and they are very reluctant to do that.  A prioritization effort involving both the customer and the developer perspectives will separate essential from desirable, needs from wants, in a way not possible from only one side’s perspective.  The customer may decide to drop the low-priority “desirables” after such a review.  The customer may actually reach this conclusion on their own and that’s a good thing, though the overall project budget and timeline may need to be changed – elimination of requirements would require a change order or series of change orders.

Read more »