Risk Management Through Coaching

To manage risks on a project we tend to follow various processes such as planning for risk management, conducting qualitative and quantitative analysis, and responding to risk. These processes include specific details such as the definition of a risk, risk triggers and thresholds, steps the team will take to identify risks, the classification and groups of risks, risk prioritization and many other little details. These processes work very well - when implemented correctly of course - and are successful in avoiding the negative consequences of a potential risk should it occur.

Besides these well known and understood project management, agility or systems engineering processes, coaching and mentoring is another powerful tool for risk management. Having another project manager as your coach allows you to get a fresh insight on project health and can hold you accountable in an informal manner to project goals and aspirations. Your coach acts as a friendly auditor and makes collaboration even fun.

Next time you manage a project don't forget to have a coach or buddy, whom you trust. You will not only gain some insights on your progress, but you will also be motivated to raise the bar.

External Project Risks More Important than Ever

As the economy becomes more challenging and the impact of globalization increases project risks become more in number and impact. Moreover external risks are closer than before. Examples of external project risks that have become much more visible during the downturn and that project managers should start accounting for if they haven't already are:

- Fluctuating currency exchange rates
- Labor issues (strikes, layoffs)
- Regulation changes
- Customer investment and purchasing changes
- Contract breaches
- Financing and investment opportunities

3 Ways To Guarantee a Failed Product

I was at the county jail a few weeks ago coaching a group of young men on strategies to transition back into society. I asked them two questions, the first list 3 goals you would like to accomplish during your lifetime, things you will be proud of in the hereafter. They jotted down some goals on 4*6 cards. The second question was list 3 things that if you do, you are 100% sure that there is no way you can achieve these goals, it will be impossible to achieve them. I gave them a few minutes and they all had a few points to share.

One example of a goal that was shared was to get back to education and enroll in college, get a degree and be a productive member of the society. The young man noted involvement with illegal substance to be a factor not allowing him to realize this goal.

Developing successful systems follow the same pattern. We need to understand user requirements, the utility of the system, why is the system needed, what value is the system offering, the gap it is filling. Once that goal is clear and understood, we need to make sure we protect these requirements from "outside noise", what is also known as scope creep. Scope creep is for sure a main reason why projects fail, it is when we add requirements, remove requirements, or just change requirements in an uncontrolled fashion, without going back to understanding the rationale and true value for doing so and relating it to the project's objective, cost and schedule.

Reason 1: Low Quality Requirements and Scope Creep - Uncontrolled Changes

A second young man in the group shared his goal was to be a successful businessman offering valuable services to the society. He noted down that unethical dealings would be a reason to ensure he never accomplishes his dream. I advised him that to overcome this hurdle he needs to continuously gauge his relationship with his Lord and measure his values and ethics. If he notices that his relationship is getting weaker, he needs to take corrective actions.

In the domain of systems development we call that validation and verification. Is the project still valid? i.e. is it still delivering what it was originally intended to deliver. And is the work correct? Can we verify that the work is what was expected earlier at the beginning of the project, through testing, and if it is not correct, can we take corrective actions to resolve defects. This validation and verification needs to be conducted throughout the whole life cycle of the product, and not just near the time we turn it over to the client, otherwise the deviations from the expected results could be huge, leading to costly modifications, schedule slippage and possibly a failed product.

Reason 2: Not Considering Validation and Verification Early in the life cycle of the product - Developing the wrong product, or developing the right product incorrectly

A third person shared that his goal was to be a teacher, nurturing young minds not only with knowledge but the application of the knowledge and its purpose. I reminded him to share with his future students trace back the purpose of the knowledge they learn from him, to the purpose for which we were created. Everything we do needs to serve the purpose for which our Lord created us.

Similarly, in the domain of product development, we can that requirements traceability. How do the original requirements defined by the client relate to design work, development work, testing and final product features. It is important that throughout the life cycle of a product we maintain a clear trace of how the work we are currently involved in relates back to what the customer needs.

Reason 3: Poor Requirements Traceability - Missing some Requirements in Implementation, adding Features not Needed, or both


Make sure if your customer asks for a mule, you deliver a mule as expected, and not a cow. Although a cow has plenty of benefits and utility, it might not serve the need satisfied by a mule.

7 Tips for Engineering Students

I often get questions or concerns from engineering students about studying and being able to pull through college to reach their goals of becoming engineers. I have to admit going through engineering school is no light challenge, but at the same time it is an enjoyable experience.

Common comments are concerns of not being able to understand the questions in an exam, or not able to go through the needed steps, or just finding subject matter too complicated.

Here is my advice for of these folks and other future engineers.

1. Understand that engineering is all about problem solving for the betterment of humanity, through the use of scientific facts. This means that a good engineer must,

• understand what the problem is (how it happens, why it happens, when it happens, where it happens)
  
• analyze the problem - visualize it (use a pencil and paper to sketch, engineers are born to sketch)
  
• determine its scope - (how big is the problem, who does it affect, under which conditions)
  
• determine what information is given to us (data, assumptions, facts)
• learn the sciences (calculus, physics, chemistry, etc..) to use in problem solving
• apply these sciences to the appropriate solutions for the relevant problems

2. Never memorize, engineers are thinkers. Anything you learn must make sense to you. You must understand why a theorem or rule is the way it is, how it came to be so, this will help with critical thinking, and will enhance information retention.

3. Do not depend on calculators too much, understand how calculations occur, understand how the value for the various engineering functions are calculated, the meaning behind a differential, or integral, etc.. Then use the calculator to just speed up calculations - remember a fool with a tool is still a fool.

4. Develop mini-processes for yourself of things to do when you analyze engineering problems, make these processes adaptive to suit your thinking styles, analytical abilities and memory capabilities.

5. Practice makes perfect. Just like spending ours in the gym pumping those muscles up, or on the court perfecting those slam dunks. Engineers need to practice solving various types of problems (easy one, long, ones, short ones, complex ones, complicated ones, straight-forward ones, etc...).

6. Be organized - learn how to manage real-estate space on your paper. Organize data, analysis, scratch notes, results, conclusion in clear separate sections of your sheet. Be a good communicator, improve your writing and verbal skills, to allow you to effectively communicate your solutions to others.

7. Love the subject matter. You can never solve a problem, you don't care about. A good engineer can never design a bridge if he cares more or less of the importance of crossing the river. Love it, adore it, live it, immerse in it... be the engineer !!

Iterative and Incremental - We Have Something to Show

On projects which follow a waterfall methodology and run into project delays, usually there is nothing to demonstrate to the client. This is a little different with iterative and incremental methodologies. Iterative meaning we repeat the life cycle processes over and over, with an incremental addition in each run. With iterative and incremental development a delayed project can demonstrate an artifact to the client. It might not be everything the client wished for, but it is there.

Iterative and incremental methodologies provide higher levels of confidence to project sponsors, who would be more willing to extend investment in a troubled project than a project with no output at all.

Agile methodologies embed iterative and incremental approaches. Examples are Rational Unified Process (RUP), SCRUM, XP and others.

Great leaders know how to scope these increments and how often should they come out. For example lets consider a generic problem well know to everyone, the current economy down fall. This problem does not have a one shot solution. A $700 billion stimulus plan will not solve it for once and for all. It is just an iteration that will yield some results in 18-24 months, to keep things afloat. Most probably another iteration will be needed to sustain some of the new initiatives started in increment 1, and so on.

We apply iteration and increment processes in our daily lives as well. When we go to the grocery store to purchase soup, we don't purchase 100 cans of soup for the full year, even if we could successfully store them and pay for them. We purchase maybe 5 or 10 cans for a week or two, we then repeat the grocery purchasing process in one or two weeks.

Reasons for iteration are many,
(a) gain confidence in an experience to decide whether to repeat it or sustain it or not
(b) streamline cash flow
(c) simplicity
(d) effective time utilization
(e) limitation in resources
(f) shorter demand cycles (time to market, constituent demand, etc..)

Effective Project Management in a Snipit

What are projects all about? A project is about delivering capabilities on time and within budget. So you are hired as a project manager at company ABC to ensure that their new product can be developed within the next six months and within budget as defined by the product team.

To ensure the delivery you need to accomplish a few basic items. Most people don't even do this bare minimal checklist below.. and guess what they wonder why their projects are among the 60%+ statistics of failed projects.

a) Understand the problem/gap the product is offering to solve (ie understand the value of the end product)
b) Define the project scope (schedule, cost, capabilities, stakeholders, assumptions, dependencies and risks)
c) Put together a good team that compliments each others skills, abilities and knowledge.
d) Define all work items that are needed to make the capabilities (product) delivered, in a hierarchical format (aka work breakdown structure - WBS), detailed to a level that can allow weekly reporting on the status of work completed
e) Define activities and their duration and resources needed to accomplish the work defined in the WBS, and come up with a schedule and cost budget.
f) Track the work completed relative to the cost and time spent to date and as planned. Are your cost and schedule variances healthy?
g) Know and track your risks throughout the project and mitigate as your move forward.
h) Ensure changes are controlled and tracked along with risks, issues, cost and schedule health.

You can be comfortable that you have a good chance of delivering your end product. Of course there are other details, but for the most part this is the backbone, if its solid, your project should be able to make it to the finish line.

Volunteer Team Members on Your Project?

Have you ever run a project that is solely or mostly running on a project team of volunteers? I was presenting to a group of program directors in the research field. Their dilemma is that they manage projects which have team members fully run by volunteer researchers from other organizations.

After comforting them that they are not the only people in the world that run projects fully dependent on volunteers, but rather they are part of the millions of teachers, religious groups, social service groups, civil rights, good citizens, and dozens of professionals who donate their time and expertise for the good cause of the World .. they became more relaxed.

So back to their challenge... How to get a volunteer - someone who is not paid, not officially or legally bound, not under your authority or control - to do their part on the project as a team member?

Answer is simple: Motivate and ensure the value they are interested in by doing this good will is present and did not disappear.

I have managed and coordinated tons of projects such as the one we are talking about. I also participated in tons where I was a team member. Bottom line --- as long as there is volunteer value. They will not only stick around, but will produce exceptional value... let it evaporate and before you know, they are all gone.

Example: Project X: Goal is to initiate, launch, implement and supervise a series of monthly community dinner at a Muslim community. Volunteers who are interested in being part of this project will most probably join for one or more of the following reasons,

a) they like food, food events, cooking, or have some passion to food
b) they like social gathering and chatting with others, like to be part of a group, or big family
c) they respect organization and like to see these events well organized and a god experience for every one
d) they just want to help out a community they belong to and enjoy being part of

So as a project manager, you know that all these volunteers are not getting paid, have very limited time, might live far away, but are interested in helping out, because they told you. As long as those 4 items above are maintained, they will keep coming. Now when something happens and for example these volunteers are no longer allowed to cook and bring in their own meals to share with others... they will not come because point a) is not longer available. Or if they feel that participants dont get along together and some tensions arise then they will stop again because point b) is no longer available... and so on.. you get the point.

So in a nutshell project manager need to have strong emotional intelligence skills and keep their eyes and ears open to what the volunteer team members are interested in and how much of it is on their projects.

Back to the volunteer researchers from all across the country that are on Bob's project (not real name). As long as the researcher's can add their work to their tenure requirements, paper portfolio, get academic recognition, be known as a participant, be respected for their knowledge and ideas, be able to have open communications with other scientists..... they should stick around.

Successful teams develop because they strive for the carrot, regardless what form the carrot takes.