Project Management – pre-preparation

Project Management

This post will look at an aspect of managing projects that is often overlooked. These are the steps you need to take prior to project commencement. The idea for this came from a presentation by Graeme Joy to the Casey Cardinia Business Group covering his expedition to the North Pole.

 

Graeme Joy with Australian Flag

Graeme Joy with Australian Flag

Planning a Project

The thing that stood out the most from his presentation was how much of the project depended on the up front planning, and how little they could do to influence the final outcome once they set foot onto the ice.

 

On The Ice

International North Pole Expedition On The Ice

So how did they do it?

 

Pick the right team

If you want a High Performance Team, then every member needs to be able to carry their weight and to be able to continue to do so during the whole of the project and in cooperation with the rest of the team members. So friction is OK as long as it leads to a good outcome. In fact you need divergent view points to prevent group think settling in.

 

So how do you pick the team members?

 

International North Pole Expedition Team

International North Pole Expedition Team

Step one is that a High Performance Team needs a High Performance Leader or leadership group. The High Performance Leader has to be able to set the scene for the purpose the team exists for and also gain commitment from the team members toward that purpose. The steps include:

 

  • Vision – Create and Develop commitment within your team. Defining success and the measurement of performance.
  • Empowerment – creating leaders within your organisation.
  • Urgency – A Sense of Urgency is critical
  • Communicate – You have to be an excellent communicator
  • Attitude – a positive attitude is more important than skill
  • Empathy – understand who your team are and what they are going through

 

Attitude is the one I want to focus on here. You can learn skills, but if your Attitude is not right, you can still fail. One example is the likelihood of survival. A trip to the north pole is entirely carried out over ice floating on top of the Arctic Ocean. Unlike Antarctica, there is no rock underneath. This carried with it two things I hadn’t considered until I heard Graeme Joy’s presentation.

 

Progress

How do you measure progress. Easy, my current position and how much closer to the North Pole am I today compared to yesterday. Seems OK. Except I am on drifting ice. They planned on making 36km per day. One day, they travelled the distance but actually went backward by 6km due to the ice drifting. It takes quite a lot of resilience to handle that. So they made sure everyone knew in advance that it was going to happen. On the plus side, one night they got 12km closer while they slept.

 

Dragging Gear Over Arctic Ice

Dragging Gear Over Arctic Ice

Survival Belief

The Arctic is harsh. Temperatures are low. Down to -55C. There are polar bears. There are ice floes and high winds and the real danger that their tent could be damaged. To emotionally prepare for this they practised sleeping in the open in just their sleeping bags in the high Swiss Alps so they knew they could survive in the event their tent was ripped.

 

Arctic Ice Tent

Arctic Ice Tent

Engineering Application

So how does this apply to Engineering, and in particular what Successful Endeavours does, Electronics Design and Embedded  Software Development? The point about Attitude is everything. Henry Ford once said, “The man who thinks he can and the man who thinks he can’t are both right“. And I agree this is the case. When we take on a project, it isn’t that we necessarily know exactly how we are going to do it, but it is with the Attitude that we will find a way. And we do. IBM statistics show that 80% of R&D projects fail. Yet we routinely succeed. It defies the statistics so how do we do it?

 

We recently took on two projects for a client who had not been able to get a solution from their current engineering services suppliers. In one case we were the third business to look at the project and the project was running more than a year late. They needed to present to their end customer in six weeks. So how can we take on that risk given two other teams have failed and with a lot more time to work with?

 

Looking at the risks for the North Pole Expedition surviving if the tent was damaged was managed as a psychological risk by trialling the risk management strategy before the expedition set out. This way they knew they could handle it.

 

In the case of the project we took on (I can’t say more because the product isn’t on the market yet) we did a quick trial and created a test rig and measured the physical parameters we would be working with and then analysed them using excel and then a program written to run on a Windows PC and trialled the solution outside the embedded environment using real data pulled from the test rig.

 

Simulation

Simulation Example – click to see full size

So we were able to see the data we would be working with and determine that a solution could be developed based on fully understanding the problem that needed to be solved. Then we started the main development phase knowing we would be able to get to a solution. And our client had confidence to authorise the additional expenditure knowing it was likely to be a good investment this time. End result, our client was able to take a working proof of concept prototype to their end customer on the expected date. And we were able to utilise most of the mechanical engineering work already done as well as the LCD panels so they were also able to leverage some of the historical investment.

 

So that was the process: understand the problem, manage the risk, do the required homework, then execute with confidence.

 

When we hire (we are hiring now), Attitude is one of the key things I assess for. Because we can teach skills. And provide experience. But I can’t overcome a defeatist or overly risk averse mindset. And I won’t hire someone who doesn’t have a hunger for the client to succeed. We exist to support Australian Electronics Manufacturers and the primary outcome I want from each project is a local manufacturing success story.

 

Graeme Joy Bio

 

So who is Graeme Joy?

 

Graeme Joy

Graeme Joy

Graeme Joy is perhaps best known as joint leader and navigator of the International North Pole Expedition, where he became the first Australian to ski to the North Pole, but he is also one of the most focused, effective and highly ranked motivational speakers in Australasia.
His extensive mastery of essential business principles such as, strategic planning, project management, conflict resolution, defining success, personality types and leadership, will answer any questions you may have and leave you feeling empowered to maximise the performance of your team.
Highly praised for his business applicability, take-home value and ability to deliver key results, Graeme Joy is also keen to share his experience with others and runs a company that conducts specialist leadership and team development programs.

The above was taken from his website. But having seen him in action, it is definitely not an exaggeration.

 

Successful Endeavours specialise in Electronics Design and Embedded Software Development, focusing on products that are intended to be Made In AustraliaRay Keefe has developed market leading electronics products in Australia for more than 30 years. This post is Copyright © 2017 Successful Endeavours Pty Ltd.

 

Improving Product Development Outcomes

In this post we will look at the Product Development Process and how to get improved outcomes. But first here is a fun graphic made from our logo.

Successful Endeavours - Making Electronics and Embedded Software Work

Successful Endeavours – Making Electronics and Embedded Software Work

Product Development Process

The Product Development Process is intended to reliably deliver new products for manufacture or distribution. This is a critical component of a Product Strategy where you are creating the product rather than sourcing it from a supplier. So you would think that it should be a highly optimised, well oiled machine that reliably delivers successful products. Alas that is not always the case. With 30 years of experience in Developing Products for a wide range of industries I have seen my share of projects handled well and not so well. Here are some general principles I have gleaned from my experience in Successful Product Development Projects:

  • Risks must be identified and managed. Track them and eliminate them as soon as possible.
  • Anything clever or tricky needs to be checked by someone else.
  • Everything else also gets checked. Design reviews, code walk-throughs and prototypes save time, money and heart ache later on.
  • Hold the timeline. Foster an attitude that slippage is not acceptable.
  • Test and check everything.
  • It’s not finished until no-one has to do another thing to it.

So six core principles. They are inter related of cousre. Let’s look at how these work out in practice.

 

Successful Product Development Principles

Lets look at how each of these priciples can be used to improve the likelihood of a Successful Product Development Project.

Risk ManagementRiskManagement

Risk Management is an old idea. Not surprising since risks have always existed. Did you know that during the Manhattan Project it was determined that there was a chance that a fission bomb could ignite the whole atmosphere ? Having got contradictory reports the argument was eventually settled by a report showing that although it was possible, it was unlikely. How comfortable would you feel running that risk ? Fortunately the average Development Project is dealing with much more mundane risks such as achieving Technical Requirements such as:

  • Power Consumption
  • Unit Manufacturing Cost
  • Performance Criteria

But the approach is still the same:

  • Identify the risk
  • Work out how to ameliorate the risk – reduce it – or eliminate it
  • Do tests to confirm the risk has been dealt with
  • Iterate until it is no longer a risk

Review the clever bits

Test Everything - Clever Design Needs Test

Test Everything – Clever Design Needs Test

Where possible, any particularly clever or tricky areas of the project need to be reviewed by someone not involved in the everyday work of the project. This is primarily to ensure that assumptions are challenged. If you can’t get an outsider to do the review, use a process like Six Thinking Hats by Edward De Bono which can allow team members to step outside their emotional and assumptive predispositions. Unchallenged assumptions are unmanaged risks.

 

Review the rest of the project

Test Everything

Review Everything

The astute amongst would have noticed that I am proposing everything gets reviewed. But the tricky bits get extra review. This section is for the regular bits. Reviews are an essential tool to find mistakes early and eliminate problems down the track. You don’t have to solve a problem you don’t have. Or as Jack Ganssle famously quipped “Skip Bugging To Speed Delivery”. That article refers to using Code Review and Design Review to find problems early and fix them so they don’t become much bigger problems later on. Imagine a scenario where a Software Bug causes an electric motor to try and spin backward every now and again and then corrected itself almost immediately. You would get a momentary shudder or jerk followed by correct motion and it would only happen every now and again. How would you determine that this was a software fault and where the fault lay? It could be symptomatic of any number of issues including Mechanical Design and Electrical Design. How about this similar real world case. I won’t mention the company, but their elevators had an Integer Overflow problem in the motor controller that caused the elevator to go in the wrong direction, about once a month, for half a floor. Very disconcerting to the passengers if they pressed up, and promptly dropped half a floor before then going up. Fortunately they found it and fixed it before it happened to someone at the top or bottom floor. All the Software Industry Metrics show for that for Software Development; Design Review, Code Review, Unit Tests and System Simulation save money and time. And yet in many projects they don’t happen enough or are done after the event as a Quality Assurance box ticking activity where they add mostly cost and little in the way of value. Lean Coding argues that you can reduce your Software Development Budget in particular by doing Code Inspections during the project as part of the Risk Management and Quality Management process. By reducing the bugging, you can reduce the debugging.

 

Stick to the Timeline

Project Development Timeline

Project Development Timeline

An attitude that the schedule slipping is normal can be very costly. Some examples of how to avoid this are:

  • Develop and Simulate the Software before the Hardware is ready
  • Prototype early and thoroughly
  • buy in IP where it makes financial sense – this can also reduce risk
  • get expert assistance with areas outside your competence
  • review regularly and honestly

As someone who has done a lot of team leading and project management, I have learned to ask about progress in more than one way. I find the following to be very common: Manager: “This module is estimated as 10 days of work to complete. How complete is it”? Developer: “About 80%”. Manager: “How many more days of work are required to fully finish everything”? Developer: “To fully finish everything, I would think 6 more days would cover it all”. The discrepancy is easy to spot. People estimate high on progress because they want to please. They also like to finish well so they tend to estimate conservatively on required effort. In practice the real answer lies somewhere between the 2 extremes. If the task had already consumed 6 days of effort then it is likely to run late. If you have ever built a house you might have experienced the knock on effect it has when one trades person doesn’t turn up and everyone else misses their scheduled action time because they are now waiting on a predecessor task, the trades person who has to come back again, before they can start their task. The same thing happens on projects. So fight hard to hold to the schedule. It is better to over resource a task (according to the plan) and get it done than to let everything and everyone slip which usually costs a lot more. Additionally, it is quite common that the later you are in the market, the lower the overall profit. So it is worth holding the schedule for this reason as well.

 

Test and Check Everything

Test Everything

Test Everything

This is another Risk Management related principle. Don’t assume it will be OK. Even if you have done it 100 times before, test it again this time. Make sure it really is OK. This ensures it really is 100% complete. This also implies that you are going to design things so they can be tested. Another principle. Design For Testability or sometimes called Design For Test. Do it. It will save you time, effort, money and sleep. Test Driven Development is another example of a Modern Development Methodology where you set up the test first then develop the product so it passes the test. If the Product Requirements change, you change the tests first, show that the old Product Design fails the test, then update the Product Design until it now passes the test.

 

It is not finished until no-one has to do anything else to it

Many tasks are called complete but they aren’t. The documents might be checked into the Revision Control System, also known as a Version Control System or Version Management System, but it isn’t complete until it is 100% tested, 100% integrated, 100% reviewed and 100% signed off and no-one has to do another thing. This also means that when tasks are identified that weren’t thought of in the original Project Plan, you then add them and don’t try and fiddle them into existing tasks. This is different to working out the fine detail of a task and realising it is under resourced or over resourced on the Project Plan. You also want the extra tasks visible on the Project Management Plan so when you do the next project you have evidence that they were required last time and can make allowances for them.

 

Trip Assurance for Developers

Satisfaction Guaranteed

Satisfaction Guaranteed

In marketing, the term Trip Assurance refers to the client having a clear expectation of this transaction or experience being a good one, just like every other one has been. I think we can begin to develop some of the same as developers whereby projects can be routinely good experiences and likely to be so each time.

 

This post is also available as an eZine article with Expert Author classification.

 

Ray Keefe has been developing high quality and market leading electronics products in Australia for nearly 30 years. For more information go to his LinkedIn profile. This post is Copyright © Successful Endeavours Pty Ltd.