I work with an IT software development organization, so most of my posts are specific to software development projects. During the testing phase, we typically experience the following problems:

1.    We expend approx 15% to 20% of the development effort in the bug-fixing phase.
2.    Our team discovers a lot of missing functionality during the testing phase.
3.    Quality assurance (QA) and development teams have different mindsets, so they understand the same feature in different ways.
4.    Test cases written by the QA are a conversion of a software requirements specifications document into an excel format.
5.    During and after the coding phase, the developer doesn't often test the application himself and instead leaves everything for QA. He tends to believe bug identification is QA's task and that the developer should only be responsible for fixing bugs.
 
    I think the software testing cycle works on the 90:10 rule: Ninety percent of the project takes 10% of the allocated time, while the remaining 10% takes 90% of the time. After expending a lot thought on this process, we came up with some solutions that may reduce the testing and bug fixing cycle:

1.    Let the QA and development teams both review the requirements and get necessary clarifications from the client.
2.    Ask the developer to give a presentation of his project understanding to QA and his module lead.
3.    Have QA prepare the test cases.
4.    Ensure test cases cover the functionality as well as the user cases and scenarios
5.    Have the developer review and log defects, too.
6.    After the completion of the coding phase, ask the developer to run high priority test cases prepared by QA.
7.    The developer should submit the test log to QA.
8.    QA shall start the testing.
9.    Each discovered bug should have a corresponding test case ID. If the test case doesn't exist for the bug, then QA should add a new test case for it. This will ensure the test cases have covered all the use cases.
10.    In the test log for each failed test case, enter the bug ID. This will ensure all bugs are raised and tracked to closure.
11.    Perform the Root Cause Analysis (RCA) for each bug and improve the coding process.
12.    Track the bugs raised by QA versus the bugs raised in user acceptance testing or bugs raised in production.
13.    Test cases should be data-oriented, and QA should be trained enough to write simple SQL (Structured Query Language) queries.
14.    The test log should show the number of rounds executed with the number of test cases that have failed, passed or have not been executed for each round of testing.
15.    Track the actual effort spent in the testing and bug fixing phases to better plan for the next module or project.
 

Are you failing to rake in the respect, admiration and monetary recompense that are consistent with your advanced level of project management expertise? If so, you need your own business or management model, complete with its own slick-sounding acronym, in order to truly set you apart and make you stand out in a crowd of (otherwise) management equals.
    This is easier than it looks. For example, someone can, say, set up a traditional Responsibility/Accountability Matrix (RAM), deconstruct them into detailed instructions with lot's of fuzzy terms like "strategic," "engage" and "implement", slap an acronym on it--like RACI (Responsible, Accountable, Consulted, Informed)--and voila! They've developed their very own management model.
    I love reading the synopses in the management course catalogues I get in the mail (yeah, I know, I need to get out more). You can almost track the entire debate among the Agile management practitioners, the Scrum advocates and the more traditional Waterfall Model believers just by reading what the instructors or paper presenters believe they are bringing to the table.
    I know: I'm inviting a truckload of comments questioning my intelligence. But Agile management strikes me as little more than the practice of loosening up baseline change control parameters to the point of almost begging scope creep to hit your software project in a bid to acquire the kind of managerial latitude needed to deliver software faster. Throw in some trendy tactics, like re-arranging the desks in the office and bring along the ever-present admonition to achieve better communications (especially with stakeholders), and then you can profoundly influence the conversation on management theory around the globe.
    I first became aware of the practice of deconstructing already-existing management practices and trotting them back onstage re-packaged during the 1980s, when "Activity Based Costing" was suddenly a hot topic. For you gen-exers out there, Activity-Based Costing (note how easily the acronym falls off the tongue: ABC) was the idea that a project's basis of estimate should be created at the lowest level of the Work Breakdown Structure, or activity level, and "rolled up" to total project cost. Problem was, this was the way that valid estimates had been created since the dawn of project management. Besides, what's the alternative? Estimating based on the availability of the organization's resources? For manufacturing, process or asset management, that might be a workable approach, but it was never so in the realm of project manager. Nevertheless, a plethora of ABC-themed paper presentations' titles started appearing in project management and cost engineering seminars. True to form, of the ones I attended, the content was made up of deconstructing the act of generating the basis of estimate into some sort of process guide--almost like a recipe--and then sprinkling in vague but trendy management-speak terms to make it appear new, or more sophisticated.
    To engage in a bit of deconstruction myself, at the end of the day all management models are nothing more than formulaic attempts at telling other people how they should be managing their projects. I can see why such models are appealing to consultants. But, for the rest of us, do they really merit all of the books, articles and presentations devoted to them?

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?  

The bad news keeps pouring in when it comes to job markets around the globe. In Israel, nearly 20,000 people lost their jobs in January. In Ireland, that number neared 37,000. And in the United States, it was a staggering 600,000.     
   While such details are simultaneously horrifying and fascinating, it raises a question: Who is taking on all the work these layoffs have left behind?
   In a recent article, Cynthia K. West, Ph.D., vice president of Project Insight, highlighted several factors that organizations, resource managers and project managers must face when job losses occur. They include:

•    Replacing resources on existing process
•    The loss of best practices, business practices and other knowledge
•    Assessing project priorities

   She goes on to say:

"The most immediate challenge that arises is the replacement of resources on existing projects. More often than not, projects in process still need to be completed on schedule--and within budget. The questions that must be answered are: Do the remaining resources on the team have the skill sets to complete the work? Can we transition these tasks without getting behind schedule? Does the organization have an effective way to look into the resource pool and know what skill sets the team members have?"

    So what is the solution?
    Ms. West makes several suggestions for managing these problems, for example she suggest organizations should put together a resource pool together to keep track of employee skillsets, while at the same time creating a knowledgebase that all employees can access and benefit from. It should include best practice documents, lessons learned, etc.
She also says it's important to ask the question, "Does this project help the organization reduce cost?" And then prioritize.  
     But what do you think? According to a recent poll here on Voices, more than half of our readers organizations' have experienced layoffs thanks to this global economic crisis. How is your organization dealing with  the mounting workloads--and making sure you don't lose any critical knowledge?

Why do we require project managers? For delivering the project on time and within the current budget. But the project manager doesn't do anything on the project--it's the team or team leads who work hard to deliver the project.
    The project manager is the white elephant that sits on top of the team and does nothing. But, if a project fails, no one in the organization complains (except the project manager) about the team. Instead, everybody runs after the project manager since he or she was responsible for the delivery (without doing anything).
    But, is there a structure in which someone else capable among the team would be responsible for the delivery? The reason I ask is because in Asia many of the small-to-medium-size IT companies are more inclined to technology rather than project management. Their success or failure depends on the technology competence and project management has little to do with it. So should the technology manager be responsible for the success or failure of the project? It seems to make more sense, to me at least, that the project manager should just help him out on process implementation, preparing the plan, providing resources, etc.

In this very first post, I would like to introduce myself. I am currently in London, England, where we had the biggest snowfall in 20 years this week.
    I started my professional life as an architect in Montréal, Canada in 1974; as such, I worked within a project environment from the beginning. Architects traditionally represent their clients and are expected to act "in lieu" of the client in their relationship with the authorities (planning department, construction permit department, etc.) other professionals (engineers, urban planners, landscape architects, interior designers, etc.) and with contractors (suppliers, building trades). After having worked in most areas of my profession, from urban planning to architectural programming, design, specifications writing and site supervising, I decided that it was time to integrate all this knowledge. So I opened my own practice and started developing turnkey projects for my clients. This meant that I needed to look at the bigger picture. It also meant that I needed to work in harmony with all the players of the project.
    After a few years, I joined a larger firm that shared this philosophy and became their director of development. That is when I started calling myself a project manager and that is also when I became member of PMI and got my Project Management Professional (PMP^®) credential.    
    During that time we developed a recognized expertise in fast-track construction. Many of these fast-tracking techniques were later adopted by IT/information sciences and are today known as "agile and iterative development." As our expertise became recognized, we got to work on large, multiphased construction projects and started to develop a reputation for pragmatic and effective long-term planning and development. Today, this type of expertise would be called program management.
    In 1996, I moved to the United Kingdom with my family. After more than 20 years of working in construction, I became a management consultant and have since practiced in a wide range of industries. I have come to realize that many organizations still don't understand how to integrate their project components to their business practices. This is especially true of the end-to-end process necessary to implement strategic decisions, realize benefits and, ultimately, create value. I intend to address these issues in my posts and hope that you will be interested in commenting.
    I travel extensively and will therefore write from different locations around the world. I am preparing to leave for Kuala Lumpur, Malaysia to attend the PMI Global Congress (where I will present a paper on the comparison between the three most recognized program management standards) and then deliver a 2-day seminar for SeminarsWorld^®.

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.

Even in these tough economic times, it's important to remember that organizations can still improve. Not everything has to be about cutbacks and budgets. (I mean, some things do, but not everything.)
    I came across this great whitepaper by @task called Driving High-Performance Projects Despite Shrinking Budgets: Three Keys to Increasing Productivity and Reducing Costs Across the Enterprise. It seems to sum things up pretty well:
    "There are many corporations getting ready for hibernation. They've already resigned themselves to crawl into a cave and wait things out. Organizations may need to reevaluate the way they do business in today's market, but there's no need to hide and let potential profits evaporate like the snow in spring. ... Project managers challenged by shrinking budgets can still drive high-performance projects."
    The whitepaper gives three keys for increasing productivity and reducing costs across the organization:

1. Make sure your organization has access to accurate information.
2. Focus on bottom-line activities.
3. Make the organization's vision accessible to everyone.
   
What do you think? Is your organization hibernating or rising to the challenge?