Tag: Project Management

3 Breakthrough Questions to Reach the Stars

Written by Christopher Cook on April 25, 2017. Posted in Articles. 4 Comments on 3 Breakthrough Questions to Reach the Stars

As a Project Manager, how many instances has the answer been right in front of you the entire time?

You spend hours and hours searching for solutions, and in the end, there it was all along.

Project Managers learn more and more each day, inputting information that later gets forgotten. This inundation of information creates an overload. There are too many ideas getting thrown around that nothing sticks.

Typically, there is a project meeting to discuss progress and future improvements to keep a project running smoothly. A team of individuals gets together and shares each of their perspectives. Every person presents a problem rarely followed by a solution.

They look to you the Project Manager for answers. You are the leader of the team so you must have the answer key locked away in a drawer somewhere. The room starts to brainstorm. At the end of the meeting, no solution is reached, and the buck stops with you.

If this is the case for a Project Manager to get back to the basics, the fundamentals of your industry and profession in project management. Now, how can I start talking about basics when breakthroughs are what we are searching for? Fundamentals seem like taking steps backward rather than blasting through the ceiling. Complexity creates confusion. Simplicity fosters understanding.

That is why these three fundamental questions lead you and your team to breakthroughs:

1. What If?

Put on your yellow hat (De Bono’s six thinking hats) and start to get optimistic. Think of the possibilities. What if your application could track progress and suggest potential changes to the customer? What if the equipment was used in multiple stages of the project? What if you used this widget instead of that widget?

These scenarios lead to discoveries. Asking the question gives you the answer. Seek out other uses for your resources.

This ‘what if’ question can be used while wearing the black hat as well. De Bono defined the black hat as devil’s advocate. Instead of asking optimistically, you question pessimistically. What if the application has bugs? What if you need more equipment than you estimated? What if this widget breaks?

Again, you are putting yourself in every situation possible. If plans worked accordingly, there would not be a need for project managers. Someone would create a plan and ‘voila,’ success.

2. Why?

A simple one-word question that is as hard to ask as it is for some people to say no. Why are we taking this project in that direction? Why do we have so many resources on one project? Why should I use this instead of that?

‘Why?’ is a probing question. It forces your audience to think. Instead of going through the motions because that is how this organization does things, why stops you in your tracks. It gives pause to the reasoning behind actions.

3. Why Not?

A contrarian question to ‘why?’ but as effective. Again, this question forces your audience to think. If something is impossible, why can’t it be done? I list this question last because it lends itself most to breakthroughs.

‘I cannot get this to work.’ Why not?

‘The sponsor will not support the direction I want to take the project.’ Why not?

‘No company has this much effort and resources towards research and development ever.’ Why not?

Takeaways

Get your team thinking this way. Force the habit of asking these questions. These questions do not have to be verbalized. Internalize them with your ideas. Be a leader by showing how to lead. Challenge your assumptions.

The ways in which you use the questions is not as important as putting these into practice. The breakthrough lies within the action.

Giving your project team a voice and fostering collaboration will help with project team chemistry. They will trust in you. Using their ideas to solve problems further enhances this chemistry and trust. This approach to problem-solving not only leads to breakthroughs but also eases the pressure and stress on you.

You are no longer the master of the answer key. The team itself holds the answers.

In what ways do you see yourself using these questions? Is it a group setting where multiple ideas can spread their wings or do you internalize them?

A Little Prep for an Efficient Project Team Meeting

Written by Brenda Hallman on April 21, 2017. Posted in Articles. 4 Comments on A Little Prep for an Efficient Project Team Meeting

A project manager should look to the most effective way to run their project’s team meetings. We are talking about your regularly scheduled meetings, typically weekly or bi-weekly.

With a minimal amount of pre-work, you can run an efficient project team meeting, get the updates needed, and best utilize the time of the attendees.

This method comprises of setting up a structure to follow the same ‘standing agenda’ as you work through your project. With a little preparation, you can have the items below available for display, or as handouts, during your meeting. You may vary the suggestions below based on the duration and complexities of your project.

1. Review Project Schedule

Prepare the schedule for the most optimal viewing of tasks. Regardless of what tool you are using to manage your tasks, you should only look at tasks that are:

Late – so you can discuss why and update the task to reflect reality and any resulting impact on new dates
Due soon – those tasks that are due to be completed through the next 14 days
Upcoming Work – tasks that are 14-30 days out to assure everyone is aware of what’s next

Consider highlighting (visually with color if possible) the tasks that most certainly need to be discussed at the meeting. Those that may have risks associated with them, those that are to be performed by individuals whom you may anticipate may have challenges in completing the work, those that are late or due very soon.

Periodically you should step through the full schedule of open work. This will provide the team a nice overview of the scale of project work and provides an opportunity to discuss concerns with future work.

2. Status of Open Issues

Prepare to review issues:

Sort by due date, with those due sooner at the top of the list.
Only show issues that are relevant to the project team, those they have reported or those assigned to them.
Only show the information necessary for the discussion. While you may be capturing various details on each issue, consider what the team members really need to see to provide updates.
Discuss those that are a high priority, regardless of the due date.
Be sure to cover issues due in the next two weeks, and review others as time allows.

3. Update on Action Items

Review any open actions items from previous meetings that are due. These are the smaller “to-do’s” that are not significant tasks requiring them to be managed on the schedule.

4. Report New Issues/Concerns/Work

Discuss anything new that has not be covered or concerns that have come up since the last meeting. Confirm that everyone is in agreement and can speak up on any items he or she believe need additional attention.

5. Summarize

Simple enough – review important actions, cover any reminders such as next meeting, and thank the attendees for attending!

By utilizing a standing agenda that follows this format, you will assure that you cover and address late work, recognize and discuss upcoming work, and focus on issues. Spending a few minutes before each meeting to prepare will provide a more organized presentation and lead your team to focus their attention on the priority topics.

Project Success and Organizational Culture – Part 3

Written by Lawrence Suda on April 20, 2017. Posted in Articles. 4 Comments on Project Success and Organizational Culture – Part 3

Just as the organization transmits its values and beliefs to its members, the project leader also creates a team culture by transmitting values and beliefs to the team members.

This process is aimed at developing project goals and objectives, group norms (how the decision will be made, how we will resolve conflicts, build trust, and actively listening and communicate). Project leaders can help the project team develop and reach high-performance levels in a number of ways.

One way is to protect the team, particularly in situations when there is a more dominate base organizational culture that may interfere with accomplishing the project’s mission. Another way a project leader can help build team effectiveness is by understanding and directly communicating the base organization beliefs and values to the project team. Providing the team with insights about potential conflicting values can help team members develop strategies to overcome potential problems. Consider a project leader who leads an exceedingly high competence core culture project team while the base organization’s core culture is an extremely collaboration core culture. The project team’s competitive behavior is very likely in direct opposition to the behaviors endorsed by the base organization. While the project leader fosters individual achievement and accomplishment, these values are incongruent with base organization’s values of cooperation and collaboration. The team will run the risk of confrontation and resistance from the base organization if they are not involved in critical project decisions. It is the project leader’s responsibility to promote a better working relationship with the base organization. The project leader must ensure the project team understands the nature and strengths of the base organization culture and develop a healthy balance between the two distinct cultures. Understanding the organizational elements and how each perceives the “way to success,” approaches tasks, relates to one another, and their particular management and leadership styles are key matters to help the project team reach high performance.

Differences in the assumptions and beliefs of each core culture and “how we do things around here to succeed,” have profound implications for the successful projects. Appreciating the values and beliefs of the base organization can help the project leader understand how to adapt his behavior and develop more effective approaches to make the project successful.

Implications for the Project Leader

Projects often have a profound impact on the organization and the people within it. Projects transform all or parts of an organization and by their very nature create change to the base organization or individual departments. Projects usually involve the design and development of a new physical product or service that may contain complex technical elements. The problem most common in a project is to concentrate and emphasize the technical content at the expense of understanding its impact on the people (users) and the organization. An important characteristic of project work is the extent to which people who will use the product are invited to participate in the work. Very often the work is done by a specialist without the cooperation, participation, and commitment of the end users.

Project leaders must be able to interact with various sub-cultural elements within their organization and that of the customer and often simultaneously. Leaders who are aware of cultural differences can avoid or minimize unproductive conflicts and misunderstandings. Differences may arise for various reasons including, values, assumptions, and beliefs and arise from problems communicating across cultures. The nature of communication in research and development is very different from the language spoken in marketing. It is important for the leader to make a concerted effort to speak and listen in ways that take these differences into account. An obstinate, hasty loom that attributes project barriers to another person’s inflexibility or stubbornness may polarize differences, escalate the conflict and make it very difficult or next to impossible to complete the project.

Projects have a higher probability of succeeding when they:

Start with the premise that organizations are living social systems.
Assess, identify, work with and align with the organization’s core culture.
Are designed on the front end from a system focused perspective and implemented in a manner congruent with that design.
Are clearly tied to the organization’s strategy
Aligned with strategy, culture, and leadership
Understand that all organizations have a lead core culture and subcultures and the key is that the project culture must function in service of the organization’s core or lead culture.

Summary

The purpose of this article was to demonstrate that project teams and organizations have unique personalities, value systems, and way they do things to succeed. The more a project leader understands the concept of culture, the more effective he will be in gaining support and guiding the project through the myriad of organization mazes.

Project leaders often engage in transactions with several different cultures simultaneously. Project leaders typically work within their own base organization core culture, with the subcultures of other departments (research and development, marketing and sales or manufacturing – each with their own inherent “ways of doing things around here to succeed”) or working with external customers and their core culture. Understanding and speaking the language of the immediate culture is critical for project success. Effectively communicating with the surrounding culture can help develop plans, strategies that are more likely recognized and time-honored, by bypassing practices that violate the beliefs and values of the client organization.

Project leaders have many opportunities to create and shape a project culture in purposeful ways, but that culture must be in alignment with the organization’s lead culture. This is an important part of project team development and a healthy team climate and stage setting to ensure project success.

Chicken Don’t Care – How Much QA is Enough QA for Your Project?

Written by Brad Egeland on April 19, 2017. Posted in Articles. 4 Comments on Chicken Don’t Care – How Much QA is Enough QA for Your Project?

Quality assurance – that necessary evil that we all must pay attention to on our project deliveries to some degree.

Don’t get me wrong, it should be part of every project, but incorporating it well into an ongoing project engagement is painful and often beyond the scope and control of the project manager and business analyst depending on a few factors, of course.

The definition of quality assurance is… “the maintenance of a desired level of quality in a service or product, especially by means of attention to every stage of the process of delivery or production.”

The “chicken do not care” phrase is something that my wife and I have been uttering almost non-stop as we have been building a chicken coop on our property out of pallets. It is turning out great, and we did a lot of online research and sketching before starting, but it is not like changes are going through a formal change review and control process. If it seems to work, feel structurally sound, and meet the needs of what we are trying to do, then we utter that statement (“chicken do not care”), implement it, and move on. We will loosely call this our scope change and quality assurance approval process.

Will that work for a regular project? Well, I think you know the definite answer is a loud, “NO!” What amount of quality assurance oversight does need to be involved in your project work, your change processes and scope management, and your customer delivery? The easy answer is – it depends. I wish it could be rigid and well defined… and the same from project to project… but there is no way that is ever going to be the case. I am thinking of quality assurance in terms of a business analyst oversight function if it has to land somewhere. The project manager must care and must be involved and help oversee it, and certainly the entire team must own it on their own tasks and deliverables and as a team. However, as far as one role truly owning it, to me, that is the business analyst who interacts with the tech team, the project manager, the customer and the customer’s end users. The business analyst role has to be where the quality buck stops and where the rubber meets the road in terms of quality project delivery.

Now, how much quality assurance that goes into any project is going to depend on a few – if not all – of these factors and more:

Public vs. private sector project niche
Dollar value of the projection
Visibility of the project
Project client demands
Length of projection
Industry of the project
Probably many, many others

Let’s at least consider each of these that I have specifically mentioned here to some degree…

Public Vs. Private Sector Project Niche

In some cases, public vs. private sector projects will differ on how much QA is needed or required. In the past, I had a top leadership role in a $50 million government project. We were required to put on formal quarterly reviews alternating in Iowa City and Washington, DC and present a formal quality audit review at each of those formal project reviews. We also had to do an annual disaster recovery demonstration. So, the focus on quality was high – probably both because it was a public sector project and because it had a $50 million price tag. This leads us to our next factor category.

Dollar Value of the Projection

Certainly, the dollar value of the project can create cause – or at least perceived cause – for more quality assurance and control oversight over the deliverables, tasks, and reports for the project. Logically, I would expect less effort and dollars to be spent on QA for a $10,000 project than a $1 million project. I do not believe any project should go QA-free. I know that some are going to get a lot more than others – and the project dollar value is going to usually be a big driving force.

Visibility of the Project

Your so-called high profile project. Is it a newsworthy project? Are industry leaders looking at your project as a benchmark project delivery? If so, then quality control and assurance better be pretty darn high. I’m not saying that should not always be the case… however, the amount of time and money you are going to be allowed by the customer and by your senior management on QA tasks and reporting is going to be swayed by the number of eyes that are on it. That is just a cold hard reality.

Project Client Demands

Your customer is definitely going to have a say in how much quality assurance goes into the effort. That may not be the case, but they will have a say as to how much money they spend on it as part of the project. If QA isn’t important to them, but it is very important to your delivery organization – as it should be – then you will likely still perform detailed QA oversight, but you’ll be doing much of it for free just to ensure you are delivering a quality end product and that your customer is happy no matter how much they are spending. You never know when that next project they return for will be that $1 million project.

Length of Project

The length of the project may factor in – though not as heavily as the project price tag likely will. A longer project that has more tasks, deliverables, and milestones also will have more chances to fall apart. Keen QA oversight can help to better keep it on track, on time, on budget and avoid many risks and re-work that would otherwise be associated with sloppy project delivery and less built-in quality assurance.

Industry of the Project

Finally, the industry of the project may lend itself to determining how much quality assurance is required. Projects being carried out in aviation, engineering, the automobile industry, health care and security – among many others – could logically demand a great deal of quality assurance and control oversight as compared to projects carried out in other genres. Agree?

Summary

We should always want to deliver quality. I know I want to but sometimes the time and money are not there to warrant the full QA effort… or sometimes others in charge at higher levels say “no”… or say “more QA!” The answer still is – it depends. Sticking to best practices in your project deliveries is still the best way to ensure daily quality project delivery no matter how much formal dedicated QA oversight there is on your project.

What are your thoughts? How much formal quality assurance oversight gets involved in your projects? What would you change or add to my list?

Why Are Projects STILL Failing?

Written by Mike Morton on April 17, 2017. Posted in Articles. 4 Comments on Why Are Projects STILL Failing?

You have heard the old joke “Do software projects really fail?” Answer: “No. They get split into phases!”

Jokes apart, the general impression, which is backed by research numbers from some of the leading organizations like Gartner and Forrester, is that 70-80% of software projects fail. Repeatedly we on the delivery side are lampooned to the point that we start disbelieving ourselves. The number of project successes seem to be as alien as finding life on Mars. Is it true that software projects fail that often?

What is failure? When any of the following 4 occur, a project is considered a failure:

the required functionality is not met
there is a time overrun,
there is a cost overrun,
a combination of any of the above 3.

There are projects that are totally scrapped for political and other reasons but I am keeping them out of this post. It will be interesting to see if someone can get the breakdown of the 70-80% failure rate among the 4 factors listed above to provide a little more clarity on where most projects are failing.

Required Functionality Not Met

The onus for this squarely rests with the project team and more so on the Business Analyst. However, I would like to add some context to this statement. In a traditional waterfall model the requirements are gathered first, analyzed and make their way through the SDLC process. In large projects the time gap between gathering requirements and UAT is significant, couple of years in some cases. In a rapidly changing world this time gap is significant as the requirements could have changed for no fault of the BA or the project team. Or the business environment is such that things change quickly (the financial crisis in 2008 drastically altered the way that banks view liquidity) or new legislation was introduced (think Dodd-Frank or Basel) that calls for a significant change in the way business is conducted. All these are beyond the control of the project team, though sufficient hints will be available (and will be seen by a keen BA) of impending changes. If nothing has changed and the functionality is still not met, the problem may have stemmed from any of the many points along the SDLC lifecycle – the requirements were poorly written, inadequate analysis, inappropriate design assumptions, no technical walkthroughs, poor caliber of the technical team, no unit testing, no SIT or poor quality of SIT, or simply insufficient time to do any of these.

Time and/or Cost Overrun

The reason I combine the two is, in most cases, because they go hand-in-hand. (In some cases, as in where the project is on hold and people are moved to other projects temporarily, there may be a time overrun but not a cost overrun). For effective measurement, there must be a benchmark. When we say a project overran time or budget then the implicit assumption is that the time and budget estimates were accurate in the first place. How often does this happen?

Generally, the time is pre-determined either by the business or the project manager or someone higher up. “The project go-live date is 30th June”. That’s it! Work backwards and figure out how to fit the SDLC within that time frame. Having scratched around we figure the requirements and analysis are due in 5 days! The time estimates are inaccurate, grossly underestimated and fundamentally wrong. Come June 30th the project is checked for completion and is given an ‘F’ grade. How fair is that?

So is the case with the budget. Estimating time and cost is an imperfect science. There are many methods that have been around ranging from the least complex-pick-a-number-from-thin-air to very complex function point analysis with a bunch of others with varying degrees of complexity lying in between. But for a few, most of the projects I have been part of the budget is determined by someone who is detached from reality and has not heard of any of the estimating mechanisms. In some instances these numbers were pruned down by the budget department. Now, what does the budget department know about the system? Zilch. Are these high-end methods reliable enough to produce an accurate estimate? No. But we have some basis for the numbers.

Why don’t many folks use these methods? Lack of time is the common answer. There is another reason too – lack of information to input into these methods. It is very interesting to note the stage at which the cost is estimated. In almost all situations the cost is estimated even before the requirements process starts! The reason is simple – “we need to create a project charter for which we need an estimate. Give us a number”. Surprisingly these guesstimates become estimates and finally serve as the benchmark against which the final results are compared.

We have an inaccurate time and cost estimate to begin with. Is it fair to compare the actual time and cost of the project against these inaccurate numbers? No, but this is precisely the conundrum we are in.

The Endless Cycle of Project Failure

Here is some food for thought to break the cycle:

Elicit requirements fully and analyze them. These costs cannot be capitalized anyway. These are sunk costs if projects don’t happen but at least they provide a greater insight.
Estimate time and cost based on those detailed requirements.
Use a reasonable estimation method to arrive at time and cost.
Compare actual project time and actual costs against these estimates.

Let’s bust up those project failure reasons to deliver project success!