Definition of development tasks and team work distribution

Or how proper planning in advance can guarantee smooth project flow – case study with examples

Read time: 20+ minutes.

Introduction and the basic list of project development phases

For any of us being a long time in the field of RND we know how complex can one project go. No matter whether the team is small (e.g. 5 to 10 people) or mid/big size (when some of the projects raise up to 200+ people) – the roadmap to navigate for a new project is many times developed at least partially from scratch and many times only some basic principles remain unchanged from older projects. Roles change, development needs change, testing can expand, people inside the projects change as well.

In a small company / teams we have several people who play multiple roles, leading frequently to one person in charge of several important aspects of the project. In larger teams we have normally a lot more tasks and thus strong profiling of most of the engineers and some specialization of the sub-teams leaders. We will take a look over the main points with one particular example, and I will present as well few errors I’ve met and few good examples for correct management.

First let’s start with task separation and planning in advance and why do we need it, or how to define the way for reaching our goals.

Jack Canfield, author of Chicken Soup for the Soul, describes his understanding of the principle of doing the small steps in this way:  “Imagine a car driving through the night; the headlights only reach 100 – 200 feet in front of the car. But you could make it all the way from California to New York whilst driving in the dark, because all you have to see is the next 200 feet. And that’s how life tends to unfold before us. If we just trust, the next 200 feet will unfold, and the next 200 feet after that and so on. Your life will keep unfolding and it will eventually get you to the destination of whatever it is that you truly want”.

Since I was a kid my grandmother, who is an ex-physics professor in Sofia University, told me many times this – whenever it is hard in life – remember to do the small steps. Stop, take a look and start taking small steps towards your goal. And to me it is the same like Canfield’s description of the road.

******* ******* ******* ******* ******* ******* *******

Of course in the field of engineering we can’t talk in unmeasurable units. Still a roadmap starts with Goals definition and every project doesn’t have anything but an idea in the beginning. Let’s first take a look over the phases of developing a single device from scratch as I have defined them for our example:

 

******* ******* ******* ******* ******* ******* *******

Example project – how from an idea for a device to develop a full roadmap with exact planning and tasks.

Our imaginary target will be a smart home controller, which will manage lights, automatic doors, video surveillance, front door video connection with voice transfer and unlocking the front door, communication via LAN / Wi-Fi for remote control, voice recognition commands for most of the functions, heating, air condition, ventilation and humidity control, and finally a touch screen main interface. It will support as well features addition and post-installation SW updates. And the purpose of this planning is to define the tasks and make finally a structured plan.

As we need some team – let’s accept we have 1 person responsible for HW purchasing, 2 mechanical engineers, 2 HW engineers, 10 SW engineers – with one of them the SW architect and another the technical team leader, 1 project manager – a total of 16 people. Any other related areas like marketing, financial and so on – we are not responsible for them when planning the development, but still our interaction is crucial – so they will be mentioned but not managed here.

Everything sounds perfect, but the picture is not complete. We shall add:

So, if we assume we have budget for 1 year of development and 6 months for initial market distribution, let’s now concentrate on the main target of this article – how to split the task in such a way to achieve the goal – completing the device in 1 year. Regarding the last list of additional critically important non-engineering tasks you can read more on how to build a startup, how to run a business and what is business at all in [1].

******* ******* ******* ******* ******* ******* *******

To start with work we need to define our SW requirements. There will be general requirements and specific ones. The specific will be for each of the functions:

1. lights
2. automatic doors
3. video surveillance
4. front door video connection with voice transfer and unlocking the front door
5. communication via LAN / WiFi for remote control
6. voice recognition commands for most of the functions
7. heating control
8. air condition control
9. ventilation and humidity control
10. post-installation SW updates
11. features addition
12. touch screen interface

We have also the following additional tasks (and each of them will require definition and specification as well):

1. Research on connection protocols – wired and wireless – to connect to all support controllers and actuators
2. Research on support controllers for most of the systems – e.g. heating will require some specific system
3. Research on the best choice for cameras – including with options like sound detection, sound activation, sound transmission to record 100% events in the given rooms (and not only images)
4. Available voice recognition solutions
5. Battery power supply to ensure working of crucial systems during power disturbances, and definition of which systems will be marked as essential in this use case scenario
6. Development of remote control smart phone application – as this is a completely different part – external partners can be searched for this, otherwise additional 2 SW engineers will be necessary to develop applications at least for Android and iPhone devices.
7. Development of the protocol for remote connection and control – that will require definition of which functions will be controllable remotely, encryption and security measures.
8. Main interface SW component – this will be the main management application, that will combine all the logic. It will get commands from a keyboard / touchscreen panel and from the voice activation component. It will then transfer commands to the actuators and functions.
9. Last despite actually first – after OS choice (and I would definitely go for custom minimalistic Linux distribution) – for part of the specific functions additional research may be necessary for libraries – free and proprietary. Especially for the voice recognition we may need an engineer familiar with the area. Or one skilled from our team who is willing to go deeper in the area. Why did we put this task last in the list? Because despite its importance – this is only after defining all other parts of the system.

Next step is defining the CPU and target HW for initial development. To do this we may use two approaches – either buying more expensive and powerful development boards, or first defining firmly the necessary CPU and resources consumption and going for cheaper boards.

I would go for the first solution. Why? Because when adding features we will need additional computational power and HW connection options, and for development – before optimizing the SW completely – we can go for a richer development platform that will provide us with different connection options. One more point – many times specific additional debugging requires more CPU resources that are not necessary in the production version. In order to achieve lower CPU consumption – our architect will have to define periodic resource utilization tests and force each engineer to comply to certain requirements during the development. And e.g. when the main development is close to the end phase – we can always put a cheaper CPU for the end-production device. There is additional way on how to make the transition easier, but I will skip here the technical details. It is enough to mention that one PCB may have two CPU footprints – one for bigger and one for smaller without any considerable price difference.

Fortunately in a contemporary electronic system the CPUs for similar tasks would not put big overhead on the production price. Why? Because a difference in 5-15 dollars per piece is nothing compared to the whole price of developing the device – that is hundreds of thousands of dollars. And if we start with e.g. 500 devices this will be not more than 7500 dollars more. But – if we have development issues during the development phase – we will literally screw the work of 15 engineers. And the price of 15 engineers even for a week is quite bigger, not to mention development complications and delays. What happens next? If we start with smaller CPU we will definitely have to exchange the HW in the future. And if we want addition of new features – again we will require new HW and more powerful CPU.

I have experienced this in several projects for automotive companies. The resulting price was high – in each of the projects we had 2-6 weeks delays of the whole project only because someone decided to keep the costs literally at absolute minimum. On the other hand – in one of the project the projection was for millions of devices, and then 1 cent difference goes for 10000 dollars afterwards. And 1 dollar goes for millions.

Conclusion – strategy choice depends firmly on the business. One shall consider more than only the development time, or only the final price.

******* ******* ******* ******* ******* ******* *******

We are ready now to start the development planning. The task is to develop a working plan from 20 functions, that each should map to the 9 main phases. Remember the step-by-step approach? Let’s simply start it with.

******* ******* ******* ******* ******* ******* *******

Phase 1 – definition of functionality and development of basic use cases.

First we have to choose whether for each function a separate engineer will be engaged with creating the specification, or we will have a small core team of 3-5 people that will be in charge of giving the resulting basic specifications to the other engineers on further phase. We have 11 functions and total maximum of 15 engineers. I would go for the first solution and would require from each of them to prepare a basic list of the requirements during the first day, in human language, that will be the base for more detailed specification. Then the project manager and the technical team lead would lead a brainstorming session (according to the rules – no negation, simply giving ideas^[2]) – to enrich the functions. Each function should be subject to one session. Then we go for another RND period of 2-3 days in which – based on the new ideas –further information is checked for available solutions, HW, connection options, etc. On the 6^th day a review is made, if necessary for some function – another brainstorming ^[2] session, and the final specification should be ready till the end of the 7^th-10^th day.

Why the whole team? We spread ideas in the team and we build knowledge of the system for all the people that is hard to transfer later. We make as well functions separation in advance, and basic function assignment. During the common meetings it is responsibility of the leader that at each meeting the team should focus on the target and stop them when attention goes away.

End of phase – Week 2. Length of phase – 2 weeks.

******* ******* ******* ******* ******* ******* *******

Phase 2 – Development of main functions logic together with HW/mechanical prototype sketches. Research and purchasing for development boards for preliminary development.

Now that we have the basic functionality, use cases and requirements specifications defined – we are ready to start the development of the function logic.

Why do we need explicit separate state like this, instead of simply starting the development? It is quite straightforward – if we just jump on writing logic, before we know good enough what should be done: 1^st – the logic will be unclear and development will go slower, and 2^nd – we will not be able to predict in advance potential complex decisions and collateral influence and interaction between the different SW components. Of course – it is not expected that at this level 100% logic will be developed. Certain use cases may be expanded during the development, others may drop out, new may be necessary. So – we need the basic ways of operation of each part of the system. On top of that – when this stage is finalized the logic of each component shall be presented to the architect and few short meetings should be done to confirm potential cross points between components. This stage shall continue again 2 weeks, with brainstorming sessions if necessary, and finally again with resulting documents with state machines and diagrams.

Why do we need documents? First of all – if an engineer wants to create something, but he doesn’t know at all how it will work – he lacks the design and basic requirements in his mind. Second – on a further development stages – it is possible that a team member is not present and neither easily accessible at certain moment – then the fastest way to check how some component works is to check the design document. Third – during the development all design specifications should be updated on a 100% regular base – whenever there is a change it shall be documented. And fourth – when we reach the final state and prepare the customer specification of the product (and also owner’s manual, installation and maintenance manuals) – we will need those diagrams to describe each function’s way of operation.

At the end of this state we will have the base for the main management application as given in function 20 from the functions support-task listing. We start designing it after having the basics of all other components as this will be the main decision making logic and it is based on all sub-functions. It will be the task of the architect as this is the core component and he is the person expected to have good overview on all sub-functions. In addition he has the responsibility to inform the team members of basic function related way of operation of the core logic. This means – the developers should be informed on the core logic interaction with each of the sub components.

End of phase – Week 4. Length of phase – 2 weeks.

******* ******* ******* ******* ******* ******* *******

Phase 3 – Choice of OS, libraries, CPU and HW according to the needs of the device with the system architect. Start of SW development with basic sub-components. Start of the real HW/mechanical development.

We have already chosen our OS. Nevertheless we have here the OS mentioned in a state as it is crucial to point out this fundamental decision. At this state our architect, the HW /mechanical engineers, the tech lead and the project manager have a really good overview of the functionality. So development of motherboard can be started, together with HW housing.

Somewhere between the middle point of Phase 2 and beginning of Phase 3 it is expected from the Architect and tech lead to have chosen and ordered development boards. The source code language will be C/C++ as most effective and the main language for a Linux based device. On top of that the boards are not crucial for the first 1-5 weeks of development as a Linux based application needs only a PC to have the base built. Also – a Linux component can be developed simply by itself on a Linux machine, so we can start the development of most of the components simply by writing code and compiling for any Linux target.

In Phase 3 the SW engineers are starting to write code, while the architect is customizing the Linux build for the OS and is making the project configuration. Phase 3 would continue 4 weeks. During this time we should have chosen as well specific libraries (in our case those for the voice recognition). At this stage we should have as well SW development started for some of the additional support tasks like connection components (e.g. a quite basic RS485 wired interface, WiFi interface, Bluetooth interface and LAN interface). We will need as well some work on the internal components connection like checking which will be the best approach to connect this and that component – sockets, pipes, message queues, shared memory, signals and files. This will depend on what was decided from the architect and the engineers during the previous phase. And of course – as this is the heart of our system – the architect should engage directly with the core logic component as soon as the basic build is configured.

–  –  –

Regarding the HW – we have here in the beginning of the phase tightly related to SW – choice of touchscreen and of exact powerful enough CPU. For the rest of the HW – choice of actuators for air condition, ventilation, heating and humidity, automatic doors, video surveillance and communication system for external door connection.

As we have 2 HW and 2 mechanical engineers, as well as 1 purchasing responsible – they have to work on the second part of this task throughout all the weeks together with each function developer. For every component research a listing of all checked suppliers shall be filled with comparison sheets of: features, connection protocols, prices, delivery times, temperature ranges, covered durability tests and any other major and minor characteristics. Reason – to keep track of what is checked, what was chosen and why it was chosen. This last point should be reported in detail to the Technical Team Lead and the Project Manager. All sheets are crucial for financial, budget and production planning. Each actuator connection options shall be checked with the responsible SW developer working on the function, as well as with the architect. We have 12 main types of HW, with some of them controlling multiple end-points like lights – we may have in a big house over 150 light bulbs and if we provide full control – we will have some special communications protocol with the dedicated lights controller.

Also – those characteristics will be the base of our marketing strategies, as normally we don’t simply provide the customer with nice features, but as well underline the covered standards and the expected conditions that need to be fulfilled (in order e.g. our product’s guarantee to be valid). And after the choice of each component is finished – samples should be ordered ASAP in order to provide the team with devices for prototypes building.

End of phase – Week 8. Length of phase – 4 weeks.

******* ******* ******* ******* ******* ******* *******

Phase 4 – Main pre-development phase with all basic components ready. Initial investigations for standardization.

We have now our boards working with first stable OS builds. We have as well some basic logic for the main management and basic touch screen controls. We have also at least some of the actuators in hand and we have few prototypes with half or more of the actuators connected. At this moment tests are done for the connection protocols, research is done if some protocols may be merged in order to reduce the wiring and simplify the installation. If we have a system that will require e.g. 400 cables to be installed in a customer house – this may prove quite difficult in an old house, where putting so many cables may require complete reconstruction. This would limit our market. Considering that nowadays we have different cable network standards and multiple wireless standards for IOT – any possible reduction of the cables is crucial. And last but not least – installation time would be reduced significantly with minimum cables, installation would be quite easier. We all know that installing complex devices requires highly skilled and trained workers, and if they have to work e.g. 3 weeks to install our system we have to pay them for 3 weeks. If they have to work only for a week – we will have to pay 3 times less and will be able to cover 3 times more customers for the same amount of time. We are building the plan now – so what I would do when planning in advance – I see that this is really important point for optimization and would have edited the steps above to put explicit requirement for phase 3 that as much as possible actuators should provide wireless connection and if not possible to search for ways of optimization with single wire or LAN network. That’s why planning in advance is important. Let’s imagine we have done this. (I leave the initial list of tasks as it is so that you can spot the improvement point. If I have already edited the text – you would have not spotted it).

As our product will be highly dependable on the customer real estate – small/big house, flat, a whole building – we need our system as well to support easy configuration and customization. This is another point of improvement that we add to the list of Support Tasks as number 22. Again I don’t add it now. Reason –  I realize this further while planning, giving the direct example of how planning in advance results in being able to digest, rethink and edit each step. This function is crucial for easy customer integration and flexibility and adaptability of our system to multiple targets – if we are able to configure the whole system in few hours we have high customer service capacity and wider customer range. Otherwise we simply will not fit any market except some specific one for building new houses with higher price.

End of phase – Week 12. Length of phase – 4 weeks.

******* ******* ******* ******* ******* ******* *******

Phase 5 – Main development phase. Full implementation of planned SW functionality together with all basic limitations, requirements, etc. Basic tests development. Basic generic test development. Basic Standards Compliance Tests Development (including with HW compliance).

We have now the complete base of the development laid down and during this phase we shall finish the planned SW functionality completely. In parallel with development we have here periodic changes in specifications as many components may have new, removed or customized functionality. In addition each SW developer should develop at least the basics of a full functionality test.

Why function based testing and not e.g. Unit Tests? Because our purpose is to check each functions integral way of operation, the combination of all state machines, messaging time lags, protocol time lags and sequences of commands, concurrent operation of each application thread and so on. Why do we start the development of basic tests now, and not leave it for the next stage? Because each SW engineer should be aware of what needs to be tested as he is developing the component. And in order to achieve this – he or she shall think on the test design in advance.

During this phase we will have as well development of integration test which will prove main and basic functionality of the system after adding new or customized functionality or features, fixes, etc. This test can be really limited, but can extend as well to check specific functions. Each engineer should be performing it before and after integration when adding to the main source database. A standard document shall be made for this.

One more specific task here will be development of any standards compliance tests – it doesn’t matter whether those are related to HW (e.g. water proofing and heat dissipation, temperature range of operation and fire resistance) or SW – durability, diagnostics, checks for memory issues or CPU load. We need those started here because some of them may require specific additional SW, or specific SW design of the components. On top of that some may require testing in external laboratories, special equipment and other tasks that would put overhead in time and money.

Regarding HW – during the previous 4 weeks all related HW should be present and any special housing should be finalized in this phase. Durability of materials should be checked, requirements for production shall be prepared.

Purchasing would work on pricing of components for HW production and systems components like cameras and actuators. It will also plan production supply and complete system price (depending on production amounts and also considering e.g. store house costs). The best book I have read on production optimization is [3]

End of phase – Week 22. Length of phase – 10 weeks.

******* ******* ******* ******* ******* ******* *******

Phase 6 – Development of full test suite for all functions, trimming of functionality, trimming of requirements, fixing issues found with tests. Finalizing all standardization tests.

At the beginning of this phase we are expected to have the full functionality developed. During phase 6 we do specific trimming of some functions and fixing any issues found with tests at the end of the main phase. We should clear standardization requirements, the basic roadmap and price estimation for production; all supply chains shall be established.  Regarding SW we are expected to enter the phase with all initial functionality 100% finished. Trimming means here that we make fine optimizations, customizations, e.g. make the voice recognition working better, improve the process of SW adaptation for different targets, we add any missing parts of the specifications.

At the moment that given application is truly finalized – all tests, documents and the production test for it should be finalized right away.

As we have all functions working we are able to finish as well the standardization tests. During this phase we will also increase the amount of on-site test in our test environment. We will start working on several documents that are crucial for the final distribution of our product:

• Manual for SW customization for different targets
• Integration and installation manual
• Maintenance and diagnostics manual
• Customer manual

Purchasing, HW and mechanical engineers will continue to finish all tasks from the previous stage to 100%.

End of phase – Week 28. Length of phase – 6 weeks.

******* ******* ******* ******* ******* ******* *******

Phase 7 – Final HW tests and finalization of mechanics/housing, etc. – with on-site integration and testing of prototypes. Finalizing any SW updates and fixes.

Now – here there is no much to add. From development point of view we shall be 100% in the phase of fixes. In case during the previous phases and this one we had good advance and there are no bugs to fix left – we can think of improvements, features additions, custom versions of the system for higher level customers and any further development.

We shall prepare for production – purchasing, HW and mechanical engineering should do any left final phases.

End of phase – Week 34. Length of phase – 6 weeks.

******* ******* ******* ******* ******* ******* *******

Phase 8 –SW and HW bug fix phase for all issues found during final tests.

End of phase – Week 38. Length of phase – 4 weeks.

******* ******* ******* ******* ******* ******* *******

Phase 9 – Standardization, certification and cleaning of potential post-development issues or user tests found problems.

End of phase – Week 42. Length of phase – 4 weeks.

******* ******* ******* ******* ******* ******* *******

End notes about this planning

I have skipped intentionally writing longer explanations in the last three phases. Read the notes below to understand why.

1. Planning a project and imagining that it will be finished exactly as planned is dooming the project in advance. Every experienced HW/SW engineer will tell you this – we can’t plan perfect projects. That’s why it is Research And Development – doing new things, many time without enough experience in the exact area. With over 14 projects behind my back – even in the really smart managed projects we had small delays here and there, enough times working overtime to partially cover current milestones. E.g. prioritizing from the 5 things left for the current release – which are crucial, which are critically important for the customer and which for the development, then saying – we stick to these 3 points, and leave the other 2 aside. This we call flexibility and customer oriented approach. Of course many times we reached the goals on time without a crisis.
2. Consequently I would always plan several weeks for crucial fixes and several for regular delays. If we plan production as well – I would put some weeks more for production start delays. These are at absolute maximum 3 months total (in a project with similar complexity). For me the standard overhead shall be kept around 20-25%. And as most experienced managers do – they plan this, but don’t mention it. They stick with the plan without delays, so that people are motivated to reach the regular goals, than use the additional time for fixes and adaptation when necessary. And for perfection of the product – good quality requires perfection and extensive testing, 100% guarantee of no glitches or unpredicted behavior. That’s why there is not much to add in the last phases – those are necessary for any delays during the previous phases and for product fine tunning. On top of that we have our plan finished at week 42, whereas a year has 10 weeks more. And again underlining – we have 3 last phases with not so much to add. Reasons – 1. people get sick sometimes, they also get holidays; and 2. when we add the additional 20% overhead – this planning should be quite successful. Finally – in case we really succeed with the planning – we switch to next phase of RND, adding more products to the line, start production earlier and go on fairs – so in any case it is a winning scenario!
3. Here we have one more aspect – when to squeeze the team and how to do it. Because if we squeeze the people all the time – they will leave us. And if we don’t push at all – everything will go quite slower. This is of course the main task of the leaders – the tech lead and project manager, sometimes supported by the architect. If we ask more from our people only in the crucial points – e.g. before a release, or before a fair and customer presentations – they will know we are playing honest, and there is a real reason for the current rush. After the given moment – we go back to normal development. After all – regarding parts of the not planned delays – it is our responsibility for not seeing them in advance as managers. And sometimes there are simply circumstances we could not have foreseen. So the advice is – stick to the balance, be honest, push hard only when necessary, but never forget completely to push. Do it gently and periodically. Otherwise the 2 months will never be enough. Again – despite that it is not written here – there will be at least some delays here and there that will be covered by the additional phases.

Now that we have the complete plan – I again point out – this is theoretical planning with one theoretical product that entertained me in creating it. One may wonder – why do we have total 16 weeks for testing compared to only 10 weeks for main development phase? Here are several reasons for this exact way of planning it:

1. I always work for guaranteeing 100% quality. Delivering zero bugs components should be the base in a startup. A big established company may allow itself the so called customer maturity phase, but even those companies are threatened by serious customer issues and losses (in product returns, post-guarantee support and – market shares) – when quality is compromised. So:
2. The main development is not stopping at all since phase 3 until phase 7. These are total 30 weeks!
3. Some components will require less work load, others will bring complications – in this case we will transfer some of the engineers working on one component to help with another one.
4. Testing however is crucial for any zero defects product. I have delivered zero defects component and in the rare occasions when I was explicitly given the chance to do this – I did it with additional 4 to 8 weeks for testing. But I had really intelligent managers that heard and understood my advice – “Give me the chance to transform the good working component at the end of the development phase to a 100% zero defects component. Give me the time to develop tests that will prove the proper operation and leave absolutely no possibility for bugs or unpredicted behavior.”
5. Testing requires in advance thinking. Some developers are not good at all in tests developments (this is based on my experience in enough teams). They need support. I needed support many years ago when I started in the area. Many don’t know that testing is not making some simple unit based per-function test, but requires tests on target, with all other components working as well, i.e. functionality testing. When we have a component consisting of over 30 functions, 3 state machines and depending on 5 other components and low level drivers, with messaging time frames dependence – such scenarios are simply not covered by some limited function based Unit Testing. The last one is merely dust in the eyes of managers not understanding what their product does and having no experience in development.
6. For any product we need as well a further EOL (End Of Line) testing for the production. And sometimes for some incoming components – pre-production check of e.g. cameras and other externally delivered products.
7. Finally another point of improvement related to testing in this plan – it lacks diagnostics planning and diagnostics component. Again I missed it intentionally so that you see how easy it is to lose a step when working on all product’s aspects and tons of data. Diagnostics is crucial for further checks of e.g. failing actuator, but it is as well good to be developed with ability of remote connection. This would provide us the chance to reduce reaction time on failure, preliminary supply of spare parts and planning of repairs when the system is installed at customer side.

Another point – the technical Team Lead, the project manager and all the managing staff plus the purchasing responsible should be involved in the development. Simply put– people that “only do purchasing” or “only do management” – do not understand the system, and consequently will not support fully its usage and creation. They will not understand the development issues, the way the final device should work. So – at any moment that those people are “free” of their original tasks – they should be involved with helping the others, testing with real HW, learn how to flash and update, run diagnostic, run basic scenarios with latest SW. Only then they will be able to support the others fully and really be part of the team, and not merely the managers, that would manage but understand nothing from the product. Not to mention that many times such people – that don’t have the full technical background – find issues that are harder to see for the technically educated engineers. Why? Because they lack some special knowledge and are closer to the real customer, closer to the HMI (Human Machine Interface) usage, closer to the regular customer expectation of how the device should work. In these free moments they can work not only on tracking and improving the team communication, but they can e.g. create customer manuals and do work that is not exactly engineering RND. Those tasks are equally important in creating the excellent final customer experience with our product. Finally – after they learn how the customer interacts with the system – they can check for competitor products, features improvement and other business related tasks.

As a result of this planning we can pull out some main characteristic one embedded system RND should have:

SW and HW planning in advance and tracing of progress

Features description and consequently requirements in advance

Purchasing

Diagnostics

Documentation

Extensive testing and standardization

******* ******* ******* ******* ******* ******* *******

So this is it – we have the product finally in our hands. I stress out explicitly again – this is a generic plan. Many times in reality phases are partially merged, a bit blending from one to the next. Some tasks require more time, other may require less – so the project manager should adapt the planning accordingly. But – it is hardly possible to finish the product with 100% quality achieved if you miss some of the steps. And if you do miss some – you will most probably have a lot future bugs, development issues, delays in the final steps of the project, including in production. This is frustrating for everyone and leads to problems, not to mention the financial and market drawbacks. That’s why the architect, the tech lead and the project manager should sit and make a basic planning with milestones in advance. I needed several days to carefully plan this theoretical device RND roadmap. I have enough experience and yet I did over 20 iterations on editing the whole plan. Imagine if I skip this and simply start doing “things”, “tasks”, pretending that I know it all in advance. In other words – each dish requires careful and exact preparation. One cannot simply put some meat, rice and vegetables in the pot and hope that it will cook itself magnificently. It won’t. We should plan and stop periodically to track progress, see what is missing, check for deviations from the original planning, check for the reasons for those, always check for feedback from our engineers, as well as from the customers. If we plan and make all the necessary steps – our dish will be like in a first class restaurant. And even our grandmothers, which for most of us looked like if they are magicians while preparing us a lunch or dinner – they can do it fast and good only because they already know the steps in advance so good, that they would never skip one.

An MBA would describe the roadmap developed above as a case study. But as this one was theoretical – let’s see few real examples from my career.

******* ******* ******* ******* ******* ******* ******* ******* ******* ******* ******* ******* ******* *******

******* ******* ******* ******* ******* ******* *******

Bad examples

1. Development of GUI together with Windows and Mac PC applications for controlling a HiFi USB connected Audio DAC.

Problems in this project were several, but first let’s start with short description of what was done. It was a working USB HiFi Audio DAC (i.e. not a prototype, but a device on market). The device was a combination of programmable logic (FPGA) and an ARM7 microcontroller. At certain point the manager (who was also the tech team lead and one of the main engineers) decided that it is time to develop a GUI for controlling the device from a PC. Before starting we never did good definition of controlling functions – which and why, how it will be controlled. We never prepared even a short informal document or sketches on this. Further the Python language was chosen due to its portability and flexibility, and it was planned to write the code in OOP manner. None of the developers that worked on it had any experience with it. None of us had either GUI development experience. The result was relatively slow and nervous development due to the many unknown issues. From point of view of the manager – he had to do some big part of the work itself, and due to the constantly changing circumstances and requirements – the team could never catch up. Enough times our manager didn’t give us enough information in advance, and was later disappointed from the results. I have taken some part in the GUI development, and finally switched completely to the task of preparing a SW installation and setup bundle and porting the functionality to MAC. In this task I succeeded, but from general managerial point of view – some time was lost, planning was never done, the team was not given time to catch with the targets and it was seldom informed on any of it. Apart from this it was a habit for this manager to change the targets without considering the consequences of the other ongoing tasks and this resulted in quite permanent chaotic development.

2. Development of GUI for a family of instrument panel clusters together with logic with a team with no experience in QNX environment (a Posix compatible OS).

The company was with enough experience in the area of automotive clusters and me and most of the other team members had from some up to quite long experience in it. From this point of view a team was chosen and it was good. However – almost all older projects were solely C based and almost none of us had experience in C++ and / or UNIX based environment. No short crash course was considered in advance, no technical team lead with experience in the area was searched for. As a result during the first 3 months we lost significant amount of time in digging here and there what is a pipe, queue and how to deal with inter process communication. During this time we had no overview of requirements. From point of view of the company we were a team of 10 developers working without any result for the first 3 months. This means 3m * 20days * 8hrs * 10people = 4800 man-hours literally lost.

Second crucial problem – requirements writing was given to external freelancers who had no experience in writing this particular type of automotive specifications. Their documents didn’t have enough annotations and despite the constant complaints of our developer’s team to the higher level managers – they didn’t even consider to understand why we complain. Problem – higher level management doesn’t check the feedback. Result – more than 7 applications (total around 14) were developed with 1 to 2 months delay due to simply unclear and incomplete requirement specifications. My application was quite complex with 3 threads, managing 480 alerts from over 16 classes, communicating with low level drivers and finally transmitting the result to the HMI. I lost those 2 months until I was finally given the original customer spec that explained quite in detail how the component should work. I was given support and finally we succeeded with the functionality, but only after the situation was already critical. And we succeeded only because I had analyzed the specifications literally up to the last letter in order to know exactly what it should do and have already developed 70% of the logic in advance. But without the help of one of our senior developers – I couldn’t do it on time.

This is called reaction acting – things screw up completely, so we start to think what should be done. But we merely react to the problems.

The correct way is to plan and think in advance – don’t start doing something you don’t know how to do. Try to understand in advance. Check your team for feedback, consider few days for planning, etc.

3. Bad task separation in a road laser scanner device.

I have been part of this project twice. At the first stage the project was young and a part of the refactoring, architecture purification and tests were given to external developers. The idea looked good, however the management team never gave the freelancers proper introduction. I was in charge of establishing the QT based test environment and did quite well. I have written HowTos, manuals and several online help and FAQ pages. So far so good, but unfortunately from this moment on we had several constant problems:

• The managers didn’t have good understanding of the architecture. Thus they were distributing tasks while learning on how to do this on-the-fly.
• The architecture was not described anywhere and our team of 6 freelancers had to dig into a structure of over 80 files with approx. 4000 lines each in order to orient ourselves in the data.
• The developers who have developed the code initially have never done code-clear sessions resulting in multiple dummy and not used classes
• The structure of the classes was a combination of 6 nested layers together with several dozens of template specialization classes. In combination with complex mathematical computations (integral and differential calculations) and normally over 60 functions and complex member structures in each class – this was literally an enormous labyrinth.
• To write the tests was hard, but manageable. Due to the lack of introduction and proper documentation we have lost at least a month more compared to if we had some information in advance. Six freelancers for a month is not nice from budget point of view. It was definitely not my job to discuss this, and I didn’t. But I was observing the results and realized that the managers who did this had completely no idea neither of the technical background of the project, nor of proper development ways. On top of that we did write approx. 75% Unit Tests and not functional tests. This is normally a loss of time just to present to some higher level managers that you have some testing. But Unit tests have nothing to do with the function, neither with the complex dependencies between components.
• The cracking point (in my opinion) was that our freelancer team was expected to write the documentation with no access to any design information, and to refactor and clear the code. How do you think is this possible? Considering you have absolutely no technical background and you have over 80000 lines of complex computational code in front of you? We did what we could, some managers have taken their fees, but despite that I’m not happy with admitting it – I have to say – this part of the task was quite a disaster. Not because we didn’t do the job. On the contrary – we did what we were asked. But the project’s benefit of it was quite limited.
• In addition the initial code was developed by external to our customer company, leading to quite a lot complications (and one of the main reasons why not to share information – partially because there was none present yet, partially because it was some company secret, and obviously someone didn’t realize that without this information good results will never be achieved).

 

What could have been done instead:

• The original team had to be asked to do the code-clear session themselves. It is quite easier to remove the unnecessary code when you have written it yourself.
• The original team had to be asked to give design documents that would have made the work of writing the tests twice faster.
• And only after the information is present to ask a company of externals to do the work.
• In other words – before giving anyone a job – be sure that you will provide him the base for his work. Otherwise you just spend someone’s budget.

******* ******* ******* ******* ******* ******* ******* ******* ******* ******* ******* ******* ******* *******

******* ******* ******* ******* ******* ******* *******

Good examples

1. Development of a family of custom OS embedded devices for mobile phones camera imaging SW

This family of projects was developed by a team of 20 SW developers with over 20 testers. The test team were mostly not engineers, and it was correct because of the consumer type of product we were developing. I started there as a tester, became a test team lead for some time and was quickly promoted to developer. The short time in the test department gave me really good base on our product.

During the development I was responsible for the sensor drivers, later for planning, training of junior developers, testing and test application development, specification writing and all complementary tasks. At some point I became as well responsible for the capture driver.

As this was consumer electronics we didn’t have so many standards to comply to, leading to less documentation in general. Despite this we had to provide 100% stability, as it was not acceptable at all for the product to have any issues (with Nokia as a customer – and at that time and one of their lower models was produced in e.g. 80 million pieces). This was the reason for extensive testing. In addition the company created a picture quality team that was responsible for all possible color, lens shading and other corrections.

The good example here consists of:

1. We made periodic milestones in advance
2. End user testing was extensive
3. I was explicitly asked to make a SW test application for my driver, that led to catching bugs in advance and easing the integration of new sensors when another project request came from the customer
4. I was explicitly asked to make documentation of the drivers – it was used for training of junior developers, reference manual and consulting document.
5. Each new project was following the steps of the previous leading to real re-use and perfection of each of the steps and making it easier and faster for us to do our job and to perfect ourselves
6. The result was over 6 projects in a row for two and a half years, all delivered on time with zero or only a few early production bugs that were 95% removed long before the product was released to the market.

All these results above were direct consequence of a manager and few technical leads that had on their mind the creation of a perfect product and having strong team integration. I’m pleased to have this experience. I still feel the satisfaction, despite any hard moments that we had.

2. Development of a door controller data management application that was finally delivered with full documentation and proven for zero bugs, tested for stability, CPU usage and time constraints.

This example has a long story. I started in the project as the person to develop the Variant Manager and was given short after this the task of creating a Data Manager. The task was never done so far and I had neither requirements nor customer specification. On top of that we worked in Autosar / OSEK OS environment and data generation was literally unclear in the beginning. And as this was the latest version of Autosar – not yet integrated in any other device in the company – none of the team members had experience with it and the new fresh SW generation tools (which were proudly left from Vector to become mature in the customer side, i.e. our team).

The Data Manager task had several stages:

1. Investigation of data saving needs of all other applications
2. Investigation of Autosar interfaces – which to use and why. In this part I had to dispute for over a month with my technical team lead until convincing him of the better approach for direct client-server interfaces that led to less memory usage and literally no time lags
3. Investigation of what needs to be generated and creating a specification. Further I requested a person to write a generator tool as without such it was practically impossible to device calibration file from over 500 separate pieces of data
4. Integrating NVM drivers and writing wrapper layer to adapt them to our system
5. I have requested assistance for one part of the NVM driver as I realized I couldn’t do it myself with the given time constraints – so the same technical lead mentioned above sat down and supported me with this for almost two weeks and we were both pleased with the result
6. I had to write the state machines for managing his lower layer and connecting it to the generated writing interfaces
7. Documentation – I had to write both the requirement specification and the design document
8. FEE driver integration and porting – because for half of our devices we were with different platform and on a different target, MCU, etc.
9. I had to write then a HowTo for the colleagues on how to add data to the generator tool, what are the characteristics of it and train them to do it.
10. I had to write as well a generator HowTo in order to keep track of what needs to be done for any point in the future.
11. Debugging and on target testing with SIL and HIL – after the technical lead wrote short SIL test for his part of the code I have developed a real time tracing test with oscilloscope and data logging to prove writing of each separate NVM block, distribution of writes, sequence of writes, frequency of writes and time lags.
12. Finally I realized we need an emergency power drop data save to ensure correct saving of the data no matter what happens.
13. The result was literally – perfectly optimized component with zero defects, tested for all possible characteristics.
14. And this is without mentioning enough side tasks.

Now – how was this possible? We have several points here:

1. My team leader gave me all the support I needed and any time that I requested help – soon such was presented.
2. When I said we need these and those types of interfaces – I have given enough test prove of what I need and as a result my team leader supported me at each step.
3. When I said this and that type of testing is necessary (and supported the decision with data) – I was given directly the green light to test it all as I consider correct (because I have justified my request completely).
4. I was given the responsibility to research with the colleagues and to train them on how to use the resulting tools
5. When I said – we need emergency power down test and proofing (and again supported this with test data) – I was directly presented the time to do it.
6. To conclude – my direct manager was checking my feedback periodically, any time or tools I needed I was presented straight away, I had team integration and the planning was always adjusted to accept each additional task.
7. Whether or not we have concluded the original full planning of the project – I never understood. But from my point of view as a senior team member – I had it all and the results were literally perfect.

If a manager succeeds to do his work in such a way that his team members feel the same way I did in this occasion – he can achieve absolutely any goal because the team works perfectly as a whole. And this should be our goal as team leaders and apart from the leading – as team members. Because a leader is nothing without it’s team, and a team is definitely not a whole part without a leader.

3. Task separation in a big project for road laser scanner device

The same project I was part of during its initial development required my and other freelancer’s assistance almost half an year later. At this moment a new and skilled project manager was hired. He did quite a good job throughout the whole project. During this half a year for each component was assigned a dedicated developer. Our task was updates of tests (now mostly functional), requirements and design documents, and code reviews. Thanks to the good task separation I was given exact piece of work, exact contact person, my feedback was evaluated, my questions answered. As a result it was possible for me to deliver what was required from me. My work resulted in update of 30% of the design document, rework 90% of the over 300 requirements, update over 95% of the functional tests and clear several critical bugs. I have delivered as well test report for all issues found. This was all possible because in addition to the correct separation of tasks during the first week, the PM organized local sessions with the architect, the tech lead and two other team leads for full description of the device, the project, the tools, the design, the documents and literally all the information we would need during our work. I was satisfied and so was our customer.

******* ******* ******* ******* ******* ******* *******

List of some useful resources:

[1]        Regarding Management:

– http://theleanstartup.com/  – a book by Eric Ries

– https://personalmba.com/  – a book by Josh Kaufman

– Entrepreneurship 101: How to Turn Your Idea Into a Money Machine – a book by Michael E. Gordon (Ignore the label under which the book was printed. The authors did good job in the area of Enterpreneurship)

 

[2]       On Brainstorming:

– https://en.wikipedia.org/wiki/Brainstorming

 

[3]       For any development or manufacturing process:

– The Goal – by Eliyahu M. Goldratt – the famous author of the Theory Of Constraints

******* ******* ******* ******* ******* ******* *******

I hope you enjoyed the article. Please leave comments below and after I review them they will appear on the page :)[/fusion_text][/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]