Results tagged “neal shen” from Voices on Project Management

I like coffee. The smell of the freshly brewed morning cup of coffee invigorates me. Just this morning I met with my mentor and I prepared as usual by getting to the cafeteria early with my cup of coffee in hand.

Our conversations usually range from project war stories to best practices and lessons learned. This time around, the discussion centered on a "must-win" proposal effort. You feel confident about the current proposal, but the day before the submission, you're called into the executive office and told the final cost must be reduced by another 20 percent.

Thoughts swirl through your head. Given that you're the project manager, you'll have to update the basis of the estimation so it supports this new, lower cost.

Many times a must-win proposal means being the lowest bidder, hoping to make up the difference from future change requests. If this is the case, then the direction from the executive office borders on unethical conduct.

Why? Because within defense contracting, a firm fixed price contract is the preferred choice for the government because any overrun would come out of the contractors' profit margin. Imagine that you know it would really take you US$100 to do the job but you bid US$80 knowing that you're the lowest bidder in order to win the contract in the first place. Once you are awarded the contract, you employ various strategies to bring to light that the customer really needs additional "enhancements" in order to fully execute their missions. Magically, the total cost of the enhancements seem to add up to another US$20, plus additional margin.

All bids must provide basis of estimation (BOE) to justify the dollar amount. On the day before the proposal submission if you are directed to lower the final bid number by 20 percent and there is no way you can revise the basis of estimation in time and you signature is on the proposal, then you are lying to get the business.

So what do you do? 

I think that if the original basis is sound and was validated through independent review, then it's the job of the project manager to say no and explain why that can't be done without compromising the integrity of the submission.

Before I could for a response, my mentor said it was okay not to have an answer right then. When that day comes, my action will be rooted in principle and on doing what's right.

Does the end justify the means?

On a personal note, I'll be taking December off in anticipation of a new addition to our family. Best wishes to you for the various holidays coming up.

Recently I had the opportunity to put together a "sales pitch" presentation to inform a potential customer about a latest and greatest widget. The audience included a vice president, a manager, some end users and a finance analyst. Since this presentation could potentially bring in a sizable amount of work for our team, I was nervous from the start.

Throughout the briefing, there were a healthy amount of discussions going back and forth between our team and our potential customer. Momentum was high after I concluded a few live demonstrations.

However, toward the end of the presentation, the infamous question came up, "How much is this going to cost?" My manager was the intended receiver of the question. There were some initial unintelligible hums followed by a long pause.

Then I interjected and started to describe a comparably scoped project that we'd done and how much resourcing it took to complete. I pointed out the similarities and proceeded to work with the audience in flushing out a detailed project scope. We concluded the briefing with a favorable impression and an agreement to continue our engagement.

As we traveled back to our office, I realized in answering for my manager that I'd decided to act on the notion that it's easier to ask forgiveness than to request permission. I am curious to know what my fellow project managers thing of this idea ...

In my case, my manger made a comment later that he would need to add "Pitch Man" to my current title. To my relief, he was smiling.  

Imagine that the project you're managing has to be "right sized" for reasons outside your control. How would you keep up the team morale?

My team and I recently went through this process. (Thankfully, if you manage projects in a large corporation, you can sometimes relocate displaced team members to other parts of the organization. On my team, some of the people were able to be relocated.)

For those who remained on the project, here's what I did to maintain morale, learning a few valuable lessons along the way.

•    Communicate to your team openly. The worst thing you can do is to withhold information. Make a plan. Reserve a portion of your normally scheduled team meetings to keep everyone up to date on the current situation and listen for any concerns.

•    Explore, don't avoid, emotions. When a team member raises an issue or concern, don't wait for the chance to sit down one-on-one with him or her. Take the time right away to listen, understand and listen more.

•    Plan a course of action. 1. Inventory your team members' skill sets. 2. Analyze team member strengths that could benefit other projects. 3. Establish a specific follow-up meeting to communicate any news.

•    Focus on the future. After the restructuring, bring the team together and set the focus on the path ahead. Communicate the roles and responsibilities to mitigate any confusion between team members, which could lead to loss of morale. Without clear roles and responsibilities, it's like trying to drive uphill with the brakes on.

This "right-sizing" exercise has been a learning experience but I hope it will be a long while before I see another one ...
 

Also see the article, Motivating Team Members in an Insecure Job Market, from PMI Community Post.

Project leaders often conduct peer reviews in an effort to improve project performance. Part of the process typically includes the review of statistical process control (SPC) analysis to continuously monitor and improve the team's effectiveness in producing quality work products.

But there's a danger for team members to just "check the box," going through the motions of conducting a peer review because they were told to do so. So while organizations may have a peer review process in place, not all of them are actually measuring just how effective their peer review process is via SPC metrics.

Organizations need to have people who are trained in the role of process mentor to review what the SPC analysis is telling you and take the time to follow up. In our organization, continuous process improvement means the combined use of SPC analysis and the art of reviewing what the analysis is telling us..

Sometimes the project manager may have to take on the role of process mentor--interpreting and discussing the SPC results with the team.

When I review a SPC analysis for a project in which items have gone awry, I try to understand what possible areas the team needs to improve upon or what resources and training the team is lacking.

If you are already performing in this role of SPC analyst? Of process mentor? What role exactly? What has your experience been like?

In my last post I said "conflicting leadership initiatives" was one of the factors leading to current overhead reductions at my company. Let me explain. Conflicting initiatives arise from the fact that senior managers do not want to trade off anything from the cost-performance-schedule iron triangle (low resource commitment with high payoff expectation which is to be delivered right now).

A decade ago, senior management got excited about agile methodologies. Instead of rushing out to do a complete makeover and implementation, the company started with small but safe pilot programs, and the results were promising.

Based on these early successes, agile methodologies were then mandated to several large key programs. But this agile mandate failed to account for the scalability of the results and project size, and these large programs soon ran into issues. (Our large projects have geographically dispersed teams including various tiers of sub-contractors and suppliers and the initial pilot programs did not model this type of project profile.)

Significant problems began to affect the company bottom line. And as soon as that happened, program managers dropped the agile mandate like a sack of potatoes and focused on fixing issues and steering their programs back to some level of stability.

Now we are in the middle of CMMI level 3 certification. Much money had to be diverted into fixing many of the gaps caused by the decades-long agile experiment. For instance, our program portfolio consists of a mixture of traditional waterfall, agile and even ad hoc projects that would prevent our business unit from reaching level 3--and not reaching it that level is simply not an option.

Originally I'd planned to write about facilitation but then I learned our team will be experiencing a 30 percent staff reduction.

And instead of going out of town, I'll be sticking around, helping management with planning and execution of the reduction. Here are my thoughts ...

In any business, there are cycles. In our particular department, we are chartered to provide services and products to internal customers who provide services/products to the external customers that pay our bills.

In our case, our staff reduction is really a leading indicator of what may be coming down the road. Several factors leading to the current overhead reduction include:

•    Inability to capture key business pursuits (in management speak, the must-win proposals turned out to be losers)
•    Too much reliance on traditional customer base--which is getting poorer each year
•    Lack of will to follow through
•    Conflicting leadership initiatives

What's happening within your work environment? Are you still experiencing these kinds of staff reductions?

Be sure to read my next post and I will explain what I mean by conflicting leadership initiatives.

How do you make good decisions? While we don't usually ask ourselves this question in our day-to-day activities, it becomes critical when we are faced with tough situations as project managers.

Several factors contribute to making good project decisions:

Experience: Experience is usually associated with time spend within the industry/domain. But while a project manager gains invaluable wisdom over time, I am a firm believer that training with hands on simulations and role-play scenarios can fast track our ability to effectively tackle challenging situations.

Process: Process refers to the training--on the job and/or formal methods--that a project manager has internalized according to their personal strengths. When I approach or encounter difficult decisions, I typically:
•    Identify the root problem by asking why multiple times
•    Prioritize options with pros and cons
•    Seek to learn from my decisions

Guiding principle(s): Guiding principle is the wisdom that project managers gain from understanding past mistakes. The principle that guides me as a project management professional is the 80/20 rule (Pareto's Law). The 80/20 rule is often observed in real life (or systems) to show that approximately 80% of the work seems to come from 20% of the sources.

When I am faced with 100 items on my to do list, I have a couple of options to tackle the workload:

•    Spread my effort evenly across all 100 items and hope for the best (meet project deadline that is)
•    Utilize the 80/20 rule--Prioritize and work on 20% tasks that when completed would bring the most value to my project.
 
In other fields such as software development, Pareto's Law is often applied to the case that 80% of the defects seem to originate from 20% of the software modules. 
 
Keep in mind that this is approximation, yet a lot of empirical data seems to point to a variation between 10% to 30%, but the name 80/20 stuck as what we the project professionals refer to in today's world.

Courage: While everyone may know the right thing, it takes courage to actually follow through in the face of adversity.

For more on using "why" as a way to define a problem, see this Tip for Team Members from PMI Community Post.

It's hard for me to predict the future. Although our team meets project deliveries, we normally range from -5 percent to +15 percent of the scheduled delivery date with one exception. We struggled on one project and finished past the promised delivery date by 50 percent of the project schedule.

We documented lessons learned much like what Dmitri Ivanenko has described in a previous post.

But I was not satisfied, so I surveyed my colleagues on how they thought we could better estimates next--and every--time.

Here is what they said:

•    Anticipate volatility and plan frequent feedback opportunities with customer. If every project you manage starts with a solid set of requirements that never changes, count yourself lucky. Most of the time, that's not the case. Be in the mindset that projects go through changes and have frequent feedback sessions with your customers to help minimize last-minute surprises.

•    Utilize both top-down and bottom-up approaches. Visions, objectives or problem statements provide the boundary of the project scope. Agree on top-level requirements and then work with the experts on coming up with quality estimates for the detailed tasks. Clarify any assumptions/questions during this time and use A Guide to the Project Management Body of Knowledge (PMBOK® Guide) processes and/or any parametric modeling tools to create the initial schedule.

•    Plan the high-risk item(s) early. How many times have you seen a schedule task showing 90 percent complete only to have it continued at 90 percent for a long, long time? Make sure the risky development work is scheduled up front. This practice gives you the greatest flexibility on mitigating risks you may not have planned for.

•    Assess your team's experience with the project effort. Understand how experienced the team is with the kind of problem you are asked to solve. And staff the project with the right people for the jobs even during planning stage. You may not need all of the positions filled, but you will need to have experienced experts to provide quality estimates.

My company is currently in the midst of delivering software that will help revamp our enterprise measurement program. In a way, we are defining the standard to which our software development projects will be graded on.

Here are some of the measurements we are interested in:

Product fault density
Requirements volatility
Defect containment
Development productivity
Hours per defect
Software size growth
Engineering percent rework
Action item aging
Risk and opportunity tracking
Earned value management systems measurements such as cost performance indicator and schedule performance indicator

The benefit of having a set of common measures for our business is quality product deliveries--which translates into increased customer satisfaction and ultimately improves the bottom line.  

Take for example the measure of fault density. This is a lagging indicator to measure the quality of the software product after the development effort has completed. This is measured in terms of 1,000 logical source lines of code (KSLOC). This measure is calculated as:

        Number of Defects/ KSLOC

The data are compared against organizational thresholds. Root cause analysis on the variance can point to issues with software complexity and insufficient/ineffective test life cycle. Keep in mind that having meaningful thresholds calibrated for your organization is the key to ensure you don't waste your time with needless analysis.

With that said, what measures do you consider important to your business?

In the book Thinkertoys, author Michael Michalko says: "To get original ideas, you need to be able to look at the same information everyone else does and organize it into a new and different pattern. This is active thinking."

What can a project manager do when he or she needs to generate new problem-solving--or any really--ideas? Try SCAMPER, which Mr. Michalko calls "a checklist of idea-spurring questions":

•    Substitute some part, activity, or operation.
•    Combine the product/process/service with something else.
•    Adapt something to it.
•    Modify or Magnify it.
•    Put in to some other use.
•    Eliminate something.
•    Reverse or Rearrange it.

Consider a meeting I had with customers who posed the challenge: "How can we improve the existing document release process?" First, we went through and identified all of the sub-processes (request change, review request, create/modify document, verify/validate document, upload document to asset library and publish document.)

Using the "create/modify document" sub-process as an example, let's use SCAMPER to ask the following:

•    What activities can we substitute within the existing sub-process?
•    How can we combine "create/modify document" with some other sub-process to improve efficiency and accuracy?
•    What can we adapt or reuse from another "create/modify document" sub-process used by other business units?
•    How can we modify the way "create/modify document" sub-process is conducted?
•    What can we magnify or add to the "create/modify document" sub-process?
•    How can we put "create/modify document" process to other uses?
•    What can we eliminate from the way we "create/modify document?"
•    What is the reverse of "create/modify document" sub-process?

With more ideas generated, a project manager has more options to explore. That is why I am always looking for tools. How do you generate your ideas?

As I write this, I am looking out of my hotel window where I can see the majestic view of the Niagara Falls juxtaposed against its man-made surroundings. Since I am away from the daily hustle and bustle of project needs, I started to think about why I really love what I do.

Project management provides me with constant opportunities to learn and apply many different skills. And the experience is never the same. It is like being a kid in a candy store, sampling different flavors. Sometimes I am rewarded with sugary sweets, and other times I cringe at the sour-tasting flavors.  

I love being able to sit down with my customers to document their needs and list requirements for the project at hand. And I always look forward to brainstorming sessions with software architects and developers..

On any given day, I could be running from a schedule planning meeting one hour to a peer review session the next. I find it exhilarating to apply various problem-solving skills.

What do you love most about being a project manager?

Taking over a software project in mid-stream can be difficult depending on how well the transition is handled. I should know, I was recently in this position when my current employer hired me as project manager about one year ago. It was my first position as a project manager. I was ready for the challenge, but anxious as to how I would best hit the road running ...
   In the first 100 days of the job, my top priority was establishing trust between myself and my team members. I needed to trust my team to execute the plan and they needed to believe that I would get them what they needed to accomplish the plan. To gain their trust, I used the following strategies:

Listening: One of the qualities of being a great project manager is communication. In my situation as someone new to the team, I practiced active listening. This is important because each project team is unique in terms of its culture, strengths and problems. And I listened to the answer. I was able to quickly diagnose the issues to start plotting the right course.

Learning: When one of the five projects that I inherited was behind schedule, I asked the crucial question "Why?" By asking this question, I began to see how best to adjust the current plan.
   I also took the time to understand past project decisions, team members' strengths, as well as stakeholder expectations. Being able to understand our stakeholder allowed me to better communicate/manage expectations for the path forward. Knowing my team members' strengths enabled me to effectively align the planned tasks with the right individuals. With good working relationships and a view of the big picture, I had one more piece to the puzzle to put into place.

Leading: I truly believed that in order to earn my team's trust and the stakeholders' confidence I must act with highest integrity and transparency. How do I accomplish this in my day-to-day activities? By consistently communicating what I plan to do and doing what I planned.
  
   There were bumps and bruises along the way, but by the end of the first 100 days, my team and I trusted each other to accomplish the goals we set forth.
   Questions to my fellow project professionals: What was your early project management experience like? And what was challenging about the experience?  

In his article Intelligent Disobedience: The Difference Between Good and Great Project Managers, author Robert McGannon, PMP, says sometimes a project manager needs to be able to "protect the organisation from itself." He suggests using intelligent disobedience.
    But what is intelligent disobedience? To explain this quality, the author used an example of the program that certifies guide dogs for blind people. During the certification process, the trainer must determine whether or not the subject dog has been able to demonstrate the ability to disregard commands issued by its master under particular circumstances. An example is the guide dog refusing to cross the street when a car is coming.
    In the context of project management, there may be times when obstacles are formidable, which prompts the project manager to pursue the following tasks as stated by the author:

•    Proposing unpopular option/opinion
•    Standing up to senior management
•    Crafting compelling arguments/justifications to garner business support
•    "Bending" rules and processes when appropriate
•    Applying non-traditional techniques to create "unexpected" impressions as a means to change stakeholder perception
•    Using communication and influencing skills to protect the organization from itself

    When might a project manager break from the norm for the good of the project? The author suggests the following situations:

•    Dealing with unresponsive sponsors or key customers
•    Managing culture clashes that inhibit project progress
•    Needing to shake-up lagging teams
•    Overcoming resistance to changing processes
•    Challenging time versus quality decisions
•    Considering intuitive versus fact-based decision making

    What is interesting is that the author points out many times we avoid engaging in difficult conversation or "sugar coat" the bad news to "preserve the current relationship with stakeholders."  We don't realize that "the conversation IS the relationship." Possible benefits from the risk of using intelligent disobedience include, engaged project teams, loyal team members and a reputation for "telling it like it is."
    My question to my fellow project management professionals is, are you a risk taker?

Editor's Note: Members can learn more about intelligent disobedience by reading the Best of Congress feature in April 2006 issue of PM Network.

What kind of picture would you paint if you were asked to see yourself being a project manager in the defense industry?
    I work in that industry and I see a culture where the pace of progress is slow due to rigid processes and traditional pyramid organizational structure.  
    In the same setting, projects are managed through the waterfall process. And although things are changing due to the current economic situation, the planning phase spans multiple years and then you move on to development, testing and deployment. And because these project budgets are in the magnitude of millions and billions of dollars, there is no incentive to "do more with less."
    I can recount the theme of the conversations I've had with more experienced project managers. They would tell me that in the old days companies earned their profits by the number of heads they staffed on projects. (Note: Cost plus contract was a popular vehicle for funding many defense projects.)
    Fast forward to present time. Cyndee Miller recently blogged on the top 10 project management trends for 2009 from ESI International. I agree with her that Leveraging Communities of Practice To Hone Skills and Navigating Virtual Teams Through Change as being nothing new to project management communities in general.
    But in the defense industry, that is not reality. What is happening at the project management frontline for defense industry is as follow:

•    Unable to come up with coherent vision and strategy, senior executives believe there is a technology silver bullet to leveraging communities of practices. Inevitably, huge enterprise knowledge tools (i.e., Sharepoint sites, wikis, engineering blogs) sit idly because no one wants to use them.
•    The idea of having virtual teams on a project meant for example that this brief work proposal is no more than 6 weeks and the company planned on temporarily co-locating the entire off site team to the main facility to work.

    In my humble opinion, there are huge opportunities for project managers to be the change agents within the industry. As long as you don't mind playing catch up, you could be the one managing projects that would safeguard our future.

Friends and colleagues, I hope 2008 was a productive year for you. No doubt some of us are already feeling the need to take another break.
    With the pressure of the economic downturn, many companies are looking for leaders who can see the big picture and motivate the mass with clear visions. I want to share a story with you. Ten months ago in a large defense company, the vice president of engineering declared that the focus for the year was going to be on defect prevention. Everyone was to do their part to ensure that quality is priority number one when products are delivered to the customers.
    The strategies to enable the vision included:
1. Adhering to rigorous formal inspection process for all product development
2. Following an extensive automated test regimen
3. Implementing additional gate reviews to ensure product quality
    Project managers soon found themselves guiding/mentoring teams on following processes, ramping up quickly on expensive software tools, and spending more time conducting "mission assurance" activities.
    All would have been well except that in the same timeframe, the vice president of the product line also announced the vision for the year: "First to market; driven business with agility." And to meet the challenging business climate, everyone needed to be focused on generating value.
    The strategies to enable the vision included:
1. Adopting the use of lean Six Sigma to increase efficiency for all product development,
2. Relying on the use of rapid prototyping--which requires early customer/stakeholder feedback--to ensure customer satisfaction
3. Less gating reviews.
    The end result was disastrous. Project teams created sophisticated enterprise applications that are still waiting to be used. Employee morale suffered because there was a constant tug-of-war between the mandates to implement more processes versus generating revenue faster.
    Sensing the frustration of their team members, project managers united to present their case to senior management on why a new direction is needed. Heeding the wise counsel of the project managers, the vice presidents made changes.
    This year, the vice president of engineering shared her vision of business success through innovation where everyone plays an important role in contributing to the bottom line of the company. Ironically, the vice president of product line decided to share his vision as well. Due to poor ratings from customers in the previous year the vision is defect prevention.