Decoding Business... A Perspective to Management!

A few thoughts popped up in my mind when I was reading Hello Laziness, Why Hard Work Doesn't Pay by Corinne Maier (Published by Orion Books, UK, 2005). As the author puts it, this is a cynical book without apology. While I do not necessarily agree with all the arguments in the book, I found a section titled Decoding Business particularly interesting and relevant. This section decodes the fundamentals of any business to five basic messages, which can shed light to running projects and leading departments.

Below, I use the main subtitles from the section. The commentary under the subtitles are my interpretations, which are typically different than those of Ms. Maier's.

Reverse The Signs
Ms. Maier argues that "the more a large company talks about something, the less there is of it." I would also argue that the dominant subject in a company is in the spotlight, this is where the focus and opportunities are. As someone once said, if you focus on the problem too much, you become part of the problem. Rather, it is healthy and productive to focus on the opportunities. If, for example, the company talk is all about timeliness of deliverables, there is no mistake about where to focus and where to make improvements. As a manager, your role is to ensure that your people know what is important for the organization and deliver results to achieve them.

Don't be Afraid to Go Round in Circles
As long as you and the organization learns from this experience. Many things in business are cyclical. We all re-learn through our own experience what others learned earlier. However, there has to be a contribution to the greater knowledge of the organization. Otherwise, going in circles does not add to the job satisfaction of the individuals nor does it contribute to the advancement of the organization.

Distinguish Stupidity from Downright Lies
OK, the title is a bit harsh but I think we all know what this means. In my opinion, people typically do not act stupidly but may appear so. In their mind, they are trying to meet an objective. The purpose of management is to ensure that the objective is a common one among the team members. In the rare case of downright lies, the action needs to be swift and decisive.

Be Realistic
We all live with constraints; resources, time, budget, you name it. And, we are constantly challenged to get to the end faster, better, cheaper. Getting caught in this circle only makes things worse for the people you lead, putting them and you into a downward spiral. Get real, say it the way it is, and be prepared to modify your plans while identifying the risks in doing so. Take your bold steps with eyes wide open.

Keep Things in Perspective
One very common mistake is to get too focused on one's own goals and objectives and forgetting about the greater goal of the organization. What good is it if one department meets its budget while causing the company to spend more in other areas? This sounds obvious but many managers only focus on what they are responsible for. Take, for example, a development team that delivers a product within cost and schedule and hands over to manufacturing a nightmare. In today's world, organizational interactions are complex and the management's behavior needs to address this complexity.

Product Cost Reduction and Architecture

With continuous cost pressures on products, companies are constantly looking for ways to cut costs out of their products. If you are in the same situation as many others, you probably are exploring your options in these two main areas:

• Re-design all or parts of the product for lower cost,
• Outsource all or parts of the product to a lower cost manufacturer.

In most cases, re-designing a product from scratch is prohibitively expensive, with questionable return on investment (ROI). Similarly, outsourcing the whole product is risky for your intellectual property, which you have heavily invested in.

When you need to cut costs quickly and with minimum risk, the obvious solution is to find the low-hanging fruits for cost reduction and tackle those areas first. But, how do you partition a product, identify and isolate the target assemblies, and ensure painless re-integration after taking out the costs? This is the main challenge that is derailing many cost-cutting initiatives.

The solution to the problem lies in the architecture of the product. Most products are not architected in the first place to allow partitioning and re-integration. This does not necessarily mean that one should give up. Instead, take the following steps to significantly improve the chances of your cost-reduction activity:

1. Create an architectural representation for the existing product. A good architecture should include, as a minimum, the following four components:
   i) Functional architecture: what does the product and its sub-assemblies do?
   ii) Design architecture: what sub-assemblies and components does the product have?
   iii) A mapping of functions to sub-assemblies: what is the function of each sub-assembly and component?
   iv) Interfaces: Identification of each interface between the sub-assemblies.
2. Identify acceptance criteria for each sub-assembly. How do you know that sub-assembly is doing what it is supposed to do?
   
3. Target one or more sub-assemblies for cost reduction. Control re-design or outsourcing through established acceptance criteria and interfaces.
   
4. Re-integrate lower cost sub-assemblies and enjoy higher profitability.
5. With the baseline you established in steps (1) and (2), repeat steps (3) and (4) as necessary.

Make Your Process Work For You, Not The Other Way Around

One of my colleagues walked into my office today and said "Some people may kick me for saying this but I love the process." This got my attention immediately, because the product development process he was referring to is one of my contributions to the organization. Here is the rest of my conversation with my colleague, whom I will call PMC (Process-Minded Colleague):

FB: [Cautiously] Why do you like it so much?

PMC: [Enthusiastically, as he always is] Because it makes my life easier; it is straightforward and at the right level of detail. Our previous process had too much detail in it and in many cases those details were either irrelevant to the project or needed modifications. But, the team members were usually not too keen on modifying activities in fear of doing something wrong.

FB: Do the team members feel differently now?

PMC: Two of the parts of the process are 1) clear identification of the decision-maker for each major activity, and 2) process tailoring tools provided to the team. It literally takes me two hours at the beginning of each project to tailor out unnecessary activities and related artifacts from my project. The fact that tailoring output is explicitly required in the process makes modification a natural exercise to go through.

FB: Glad to hear this! The purpose of the decision-maker identification and tailoring was to exercise the team to come up with what makes sense in each project. It is meant to be a cover-all process, and by that definition, significant chunks of it may be irrelevant to a smaller project. For example, a derivative product development project does not require all the steps that would have been required in a new product platform development project.

PMC: And, better yet, we still need to run the tailored version of the process with the decision-makers to ensure that we are not missing something in the larger scheme of things. It is a great way to catch out-of-project knowledge while explaining the tailored version to the stakeholders. In the old days, we did not have the forum for such a discussion and typically there would be something that comes and bites us way too late in development.

FB: I guess we should give ourselves a pat on the back and work on making it better.

PMC: Yup, I am on it, see you later!

My moral of the story was that we got three aspects of the process development right:

1) Develop an all-inclusive high-level activity plan in the process flow,

2) Identify the stakeholders and decision-makers,

3) Provide the tools to the project team and require the team to tailor it to suit their needs.

Software Requirements - Four Fundamental Tools

Your product development methodologies may be inspired by waterfall, agile or, most likely, a combination of the two. Whatever your development practices may be, the way requirements are managed plays an important role for the success of your projects. Many organizations and developers consider requirements as written statements. In fact, visual representations of the requirements typically add significant value to the understanding of the product to be developed when little information is known about the required functionalities and features.

Visual representations continue to be useful beyond the confines of one development project and can be helpful in future derivatives by creating a solid baseline for the product.

There are a number of representations to choose from and they all have their value in different situations. Here, we discuss four of them, which are used as the fundamental requirements representations at MDS Sciex (http://www.mdssciex.com/), a division of MDS Analytical Technologies, in the early phases of software product development.

1) Context Diagram: A powerful and simple way to describe the scope of the product to be developed. The diagram clearly shows the context of the product and identifies the interfaces and the interactions of the product with its operational environment.
2) Task Flows: represent the typical and atypical tasks and activities performed by the user who will be using the product. A task flow provides a simple graphical representation of core user requirements for the product by describing how the users perform their everyday tasks, which include the tasks targeted by the product to be developed.
3) Product Navigation Models: show how the product operates. Product Navigation Models are often shown with User Task Flows overlaid, allowing verification of how well they support the Task Flows.
4) High-Level User Interface Design: provides a common, high-level view of what will be built, from the target audience’s perception. This is where we start to introduce more detail compared to the previous three artifacts. Key frames are wire frame drawings of key components of the user interface. A low-fidelity sketch of a user interface component; it includes indication of the type of information shown and main functions available, and shows a potential, general layout. Visual details and secondary functions are either omitted or preliminary.

These artifacts form the foundation of software requirements in an Agile software development environment at MDS Sciex.