How to solve it?

Summary of G.Polya's method for problem solving

UNDERSTANDING THE PROBLEM
First. You have to understand the problem. What is the unknown? What are the data? What is the condition? Is it possible to satisfy the condition? Is the condition sufficient to determine the unknown? Or is it insufficient? Or redundant? Or contradictory? Draw a figure. Introduce suitable notation. Separate the various parts of the condition. Can you write them down?

DEVISING A PLAN
Second. Find the connection between the data and the unknown. You may be obliged to consider auxiliary problems if an immediate connection cannot be found. You should obtain eventually a plan of the solution. Have you seen it before? Or have you seen the same problem in a slightly different form? Do you know a related problem? Do you know a theorem that could be useful? Look at the unknown! And try to think of a familiar problem having the same or a similar unknown. Here is a problem related to yours and solved before. Could you use it? Could you use its result? Could you use its method? Should you introduce some auxiliary element in order to make its use possible?
Could you restate the problem? Could you restate it still differently? Go back to definitions. If you cannot solve the proposed problem try to solve first some related problem. Could you imagine a more accessible related problem? A more general problem? A more special problem? An analogous problem? Could you solve a part of the problem? Keep only a part of the condition, drop the other part; how far is the unknown then determined, how can it vary? Could you derive something useful from the data? Could you think of other data appropriate to determine the unknown? Could you change the unknown or data, or both if necessary, so that the new unknown and the new data are nearer to each other? Did you use all the data? Did you use the whole condition? Have you taken into account all essential notions involved in the problem?

CARRYING OUT THE PLAN
Third. Carry out your plan. Carrying out your plan of the solution, check each step. Can you see clearly that the step is correct? Can you prove that it is correct?

LOOKING BACK
Fourth. Examine the solution obtained. Can you check the result? Can you check the argument? Can you derive the solution differently? Can you see it at a glance? Can you use the result, or the method, for some other problem?

The Phoenix Checklist

This is an effective checklist for approaching a problem; I am not sure where I picked this up from

The Problem

Why is it necessary to solve the problem?

What benefits would be received by solving the problem?

What is the unknown?

What is it you don't yet understand?

What is the information you have?

What isn't the problem?

Is the information sufficient? Or is it insufficient? Or redundant? Or contradictory?

Where are the boundaries of the problem? Can you separate the various parts of the problem? Can you write them down? What are the relationships of the parts of the problem?

What are the constants (things that can't be changed) of the problem?

Have you seen this problem before?

Have you seen this problem in a slightly different form?

Do you know a related problem?

Try to think of a familiar problem having the same or a similar unknown?

Suppose you find a problem related to yours that has already been solved. Can you use it? Can you use its method?

Can you restate your problem? How many different ways can you restate it? More general? More specific? Can the rules be changed?

What are the best, worst, and most probable cases you can imagine?

The Plan

Can you solve the whole problem? Part of the problem?

What would you like the resolution to be? Can you picture it?

How much of the unknown can you determine?

Can you derive something useful from the information you have?

Have you used all the information?

Have you taken into account all essential notions in the problem?

Can you separate the steps in the problem-solving process? Can you determine the correctness of each step?

What creative thinking techniques can use to generate ideas? How many different techniques?

Can you see the result? How many different kinds of results can you see?

How many different ways have you tried to solve the problem?

Can you intuit the problem? Can you check the result?

What should be done? How should it be done?

Where should it be done?

When should it be done?

Who should do it?

What you need to do at this time?

Who will be responsible for what?

Can you use this problem to solve some other problem?

What is the unique set of qualities that makes this problem different from another?

What milestones can best mark your progress?

How will you know when you are successful?

 

Is CMMI still relevant?

Not Any more, well at-least not as relevant as it was a decade or two back

Why do I think so? 

Fundamentally, any innovation or improvement (be it product or process), is envisioned and adapted, to solve an existing problem or exploring new opportunities. So the founding fathers of CMMI were surely trying to solve a problem that was prevalent those days.

So what problem did they solve?

In the Late 70’s & early 80’s Software Development projects spanned multiple years and huge programs were split to multiple projects and sub-contracted to multiple vendors.  The enormous size and complexity of the tasks resulted in lot of wastage of $$$ due to delayed and cancelled projects.  (Read: Mythical Man-Month).  To arrest this problem, the US Government, Industry and Academics got together and created a process model which would help Assess the process maturity of the contracted organizations, thus improving the predictability and increase the confidence towards meeting committed Schedule & Quality. Of course this evolved over a period of 6 years, between 1985 to 1991 undergoing multiple iterations. (for a brief on the history of CMMI see:  “A history of the Capability Maturity Model” by Mark C. Paulk). Subsequently, It became the de-facto Assessment of Organizational Capability & Maturity at delivering software to customers on Time & with Quality.

So why is not relevant anymore?

I would argue on three grounds

a) The Problem that CMM intended to solve does not exist anymore. Today’s projects do not span such durations, and our confidence levels have significantly improved. (Compared to early 90’s) .

b) In economic terms the marginal value that CMMI Certification provided to a Organization, (against an org. that is not certified) was significantly higher in 90’s and it is continually reducing. (Law of diminishing returns) .

c) Today’s problems are of completely different nature and complexity, and our Processes needs to be assessed for capability to meet today’s challenges.

So what are today’s Problems?

The rate of change in Technology, Consumer preferences and Market is exponentially higher than what it was 2 decades back.  Organizations are now scrambling to be adaptive to these changes & exploit the market and existing resources, without losing focus on Innovations. Hence companies today require having Adaptive & flexible processes.  The processes themselves should help support maximizing value to customers while improving continuously.  They should support and nurture Innovations to explore new market opportunities. 

Any assessment of Organizational Capability or Maturity should assess their ability to be Innovative and operate effectively in an environment of constant flux while staying profitable. 

The toad and the hot water

Various biological studies have shown that if a toad is placed in a container along with water from his own pond, he will remain there, utterly still, while the water is heated, even when the water reaches boiling point. The toad does not react to the gradual increase in temperature and dies when the water boils. Fat and happy.

On the other hand, if a toad is thrown into that container when the water is already boiling, he will jump straight out again, scalded, but alive!

Sometimes we behave like the boiled toads. We do not notice changes. We think that everything is fine and that anything bad in our lives will simply go away - that it's just a matter of time. We are close to death, but still we sit, unchanging and apathetic, while the water around us gets hotter by the minute. We end up dying, fat and happy, without having noticed the changes going on around us.

Boiled toads do not understand that, as well as being efficient (doing things right), they need to be effective (doing the right things). And for this to happen, there must be continual growth, with room for dialogue and clear communication, room to share and to plan and to build an adult relationship. The biggest challenge lies in having the humility to respect someone else's views.

There are, however, boiled toads who still believe that the most important thing is obedience, not competence: those who can, lead, but those with any sense, obey. And where does this leave real life?

It is far better to emerge from a situation slightly scalded, but still alive and ready to act.

Copied From one of Paulo Coelho’s books

LEAN Behaviors

We keep talking about culture change when we refer to lean. In fact it's an attitude change.

I call it Lean Behavior.

 

Here are some differences in attitude between the Traditional thinking and lean thinking. Lean thinking is very optimistic. It engages people fully. They feel appreciated and trusted. Inner resources surface and motivation is strong.  They keep looking even more fervently how to get rid of waste that eats away at their wealth.

 

We’ve never done it before _____ We’ll be the pioneers

It’s too complicated ___ Let’s look at it from a different angle

We don’t have the resources ___ Necessity is the Mother of Invention

It will never work ______ Let’s give it a try

There-s not enough time _____ We’ll reevaluate our priorities

We already tried it _______ We learned from the experience

There’s no way it will work _____ We will make it work

It’s a waste of time ______ Think of the possibilities

It’s of waste of money _______ The investment will be worth it

We don’t have the expertise _______ We’ll benchmark those that do

We can’t compete ________ We’ll get a jump on the competition

Our vendors won’t go for it ____ Let’s show them the opportunities

It’s good enough ________ There’s always room for improvement

We don’t have the money __________ Can we afford not to?

We’re understaffed _____________ We are a lean machine

We don’t have the room _______ We better organize our space

It will never fly __________ We’ll never know until we try

We don’t have the equipment ______ Can the equipment be rented?

It’s not going to be any better ______ We’ll try it one more time

No one communicates _________ Let’s open the channels

Isn’t it time to go home? _____ Days go so quickly around here!

I don’t have any idea _______ I’ll come up with some alternatives

Let someone else deal with it ____ I’m ready to learn something new

It’s too radical a change _______ Let’s take a chance

It takes too long to approve _____ We’ll walk it through the system

Our customers won’t buy it _______ We’ll explain the benefits

It’s not my job ____ I’ll be glad to take the responsibility

 

I CAN’T ________________________ I CAN

 

 

 And that is lean thinking.

 

I picked this up from here:

http://www.implement-lean-manufacturing.com/lean-thinking.html

 

 

Lean Thinking

The image and metaphor we like to convey a key thinking mistake and opportunity is the sport of relay racing.

 

Consider the relay racers standing around waiting for the baton from their running colleague. The accountant in the finance department, looking aghast at this terrible underutilization ‘waste’ indicated in some report, would probably mandate a policy goal of “95% utilization of resources” to ensure all the racers are busy and ‘productive.’ Maybe—he suggests—the runners could run three races at the same time to increase “resource utilization,” or run up a mountain while waiting.

 

Funny…but this kind of thinking lies behind much of traditional management and processes in development and other domains.

 

Of course, in contrast, here is a central idea in lean thinking: Watch the baton, not the runners

Results

Results… are the outcome of a process. What we want are good results from a controlled process because they will be repeatable. Bad results from an uncontrolled process simply mean that we’re not doing our job. Good results from an uncontrolled process…only mean we’re lucky. Today, a bad result from a controlled process just says that we’re stupid: We expect different results from doing the same thing over again.

Four Men

It chanced upon a winter's night, Safe sheltered from the weather,
The board was spread for only one, yet four men dined together.
There sat the man I meant to be In glory spurred and booted.
And close beside him to the right The Man I am reputed.
The Man I thought myself to be his seat was occupying,
Hard by the man I really am who to hold his own was trying.
And all beneath one roof we met, yet none called his fellow brother,
No sign of recognition passed ... They knew not one another.

 

… Author Unknown

Product Transitions or problem transitions

As a PM responsible for enhancements or maintenance of a product, that has been recently acquired by your org. You need to think twice before making any commitments. During an acquisition, in most cases the potential revenue or profit that can be generated takes precedence over the technical or engineering aspects.

The engineering team gets to have a look at the product from under the hood, only when it gets transitioned, and they are proclaimed to be responsible for the same in the future.

 

It is the PM’s core responsibility to check on the following before making any commitments on maintenance or enhancements.

 

a) Ensure that all of the necessary source code and rights to use / modify the same is available

b) Ensure availability of engineering & User documents,

c) If any third party components are used, check that the required licenses are available and support contacts are established

d) Allow for the engineering team to look under the hood, and get a good grip on the same.

e) Allow for the QA team to check on the quality and confirm that behaves the way it was expected, or whatever is mentioned in the user guides and marketing brochures are actually true

e) There will be push from all stakeholders requesting for updated product with fixes or enhancements at the earliest.

f) Resist the temptation to make any commitments (wishful thinking never helps)

 

If you are pushed to commit, indicate all of the above as risks of high impact and shout as loudly as possible (in writing), it’s ok if nobody listens to you, as long as you have evidence that you did shout.

A Case for Reqmnts. Engg. Group

If Organizations have a Process Group, Program management Group, Systems engineering group… why not a Requirements engineering group.

 

If projects are subjected to Cost and schedule over runs, one of the top causes for the same can be attributed to Poor Scope definition. So is it not imperative that organizations give due importance towards Collecting requirements and Analyzing them. (Thus enabling successful projects)

 

This would require specific skills set which would include VOC collection, interviewing, facilitating brainstorming, negotiating, and knowledge on latest technical advancement. A bit of domain understanding would be an added advantage.

While the above set of skills are about collecting information, the next set of equal importance is about the ability to clearly communicate the same in written form.

This requires the understanding of different visual representation and appropriate use of such options which include, use case scenarios, flow or process diagrams, sequence diagrams, data dictionaries etc.

Topics for Articles

Planning to write two articles in the next few weeks,

 

The first one will be about “managing Integration Projects” This would be based on experiences related to a) Projects involving procurement of a Sub-component or service from an external vendor, b) Joint development with external organizations or vendors as part of a larger solution or c) multi-site development for a software product.

 

The Second one will be about the “importance of scope definition”. Attributing most of the Quality problems in software to poor scope definition. I will discuss on the reasons for poor clarity on scope, or the difficulties associated with capturing the scope, and what can a PM do to address such scenarios.

QA Perceptions or end user needs

During the software development process, we come across situations where the team would brainstorm on how the end use would use a particular feature, or the steps the end user would do to get a certain task accomplished.  In most of the cases these small details cannot be validated with the customers. In such instances, The Developers take help of the QA personal (as an end user representative). Often the QA team has a different perception as against the developers. Then usually the Implementation happens in accordance with the QA recommendations.  

 

I tend to wonder these days, if we are developing the product according to the QA Team members’ perceptions or what the end user requires

 

unit Testing / Code Reviews

Every individual developer who writes code has an obligation to ensure that the code satisfies the needs, that it was intended to serve. Other then the stated need, an implicit assumption is that it is robust enough. The Developer needs to review or test his piece, to ensure that.

 

So what should the developer check for?

 

Input validation

Any piece of code usually has some kind of an input, either through a UI, or as parameters for the function/ method or Data that is read from a file, db or some temp memory location.

is the value within the expected min/max limits, is it null, is it one of the expected values(in case of enum), is it numeric / alphanumeric / allowed special characters, is it the incoming data too big that it does not fit into the expected data type size limitations. Is it in valid format? (For example dates, regular expressions) 

 

Valid Comparisons

Any comparison between two variables, x==y needs to checked if x & y are of compatible data types,

mode of comparison is also an important consideration, equals, less then, greater then, like, which is the appropriate one to use, based on the requirement or circumstances. has less then been used when less then or equal to is more appropriate, or is equals used, when like is more appropriate, ensuring that the condition being checked will return both true / false and is the correct set of statements under true / false or is it reversed. These are the kind of questions to ask oneself

 

Loops & Conditions                                         

All kinds of loops and associated conditions such as select / case, while, for loop, will need to be looked at to check if, either the first element or last element may be left out, or the possibility of overshooting the no. of elements, problems due to the index (starting from 0 or 1), conditional checking such as < or <= which is the correct one? Proper use of break or continue to ensure that exit from loop happens, a default else or a default case, in case of a switch or a select case statements. another item not necessarily of the same category is recursive functions related problems, which need to be looked for.

 

Assignment - type mismatches

When the language being used allows implicit conversion among data types, there is a possibility of wrong assignments, a variable declared as a string might be assigned a number, date etc. but when reading from that variable and converting back, you will tend to get errors related to data type mismatch. when creating a variable of date/ time and assigning value from another input variable, then format, related issues may crop up especially when supporting I18N, 04/11/2008 may be interpreted as 11th April or 4th Nov, need to be watchful of such possibilities.

 

File and DB Access points

Another important area is proper closure of connections and freeing up of resources, in case a file is opened and read, has it been closed and the memory assigned been properly disposed. this applies on similar lines to Database connections also. Are the db objects such as record sets closed, if not, this may result in unwanted row level or table level locks. Resulting in a wait for ever, until the process is killed.

the same applies to files too.

 

Standards & Consistency

From a readability perspective the code can be checked for naming conventions, proper indenting, correct and relevant comments etc. well structured, preferably with an header indicating the purpose, and where this piece fits in the big picture.

 

 

Exception handling

In all of the above scenario's of failure conditions, having a mechanism to capture those exception cases, and logging that information for debugging purposes, and throwing a meaningful application defined error / exception message back, is important, during a review process we could check if all of the important areas where possibilities of exceptions are high, have the relevant mechanisms to catch them.. btw, this can be handled as a separate topic in some future discussions (possibly... not probably J )

 

 

I guess taking care of these, should make the code good enough, and ready for integration with other parts of the system.

Types of Integration (problems)

Integration can mean a lot of different things. But for our know-how we will stick to the scenarios below (for now).

 

Projects can be of many flavors; I have come across a few like the ones described below, let us dwell on the details of the advantages and Risks involved in each of these scenarios separately.

 

Project Management Related

 

Multi – location Development

 

The Multiple modules that form part of the Product may be developed by team members who are working from different geographical locations.

The main challenges faced are related to Time differences and Cultural differences. Good Clarity on expectations of Quality of the deliverables from each of the teams, having realistic timelines considering the local culture and calendar are key to satisfaction here

 

Procurement of Components

 

The Project may involve using a third party component as part of your product or service, You will usually base this decision on the fact that it is cheaper to buy then build it yourself, or you do not have either the competency or the time required to build.

The main challenges here are related to licensing the product, rights to re-distribute, future support availability, maximizing the utilization, in lieu of the price paid. Etc. There are cases where the vendor is asked to make a few changes or customize the components to your needs.  The Key here is to ensure that the vendor will continue to exist in the future, will be capable of providing timely support, and the procured components meet your quality expectations.

 

Joint Development

 

Two or more organizations may want to leverage each others strengths to capitalize on a market opportunity that requires them to work together to create a solution. This is the most tedious for the PM to manage, This includes the challenges in the above two scenarios, and also the added responsibility of qualifying each of the Individuals deliverables and the solution as a whole. Other bottlenecks may include revenue sharing, and agreements on providing technical support to customers. If not handled proactively, problems arising at installed locations can be tossed around as not my problem, or it’s on his side of the fence.

 

 

Technical Issues      

 

Data Mapping

 

When sharing information between two products, The data representation and Semantics of one product will not be the same as the other product. Identifying these dis-similarities and resolving them in mutually acceptable terms is always going to be a pain. A lot of Integration related problems arise from this mis-match if not captured during Requirements and Design stages.

 

Module or Component Interfaces

 

When the parts of a solution are developed separately, either in-house or procured, as and when these parts need to gel or work with each other. Interface mis-match issues crop-up resulting in a lot of re-work and schedule slippage to get the pieces to work in unison. Clarity in communicating the problems to the concerned teams, and getting it resolved will take multiple interactions. Geographically dispersed teams and working with teams outside the organization can further strain to the developers

 

 

This is not an exhaustive list of categories; just a few that I have come across in the last couple of years.  I will explain further details of problems and solutions related to working with external organizations and joint development in a separate article.

 

 

                                                                                     

 

                                                                                    

 

                                                             

Integration - Convergence

While the simplest of integrations may involve a straight forward Data transfer between two backend Data stores,
Next on the line can be a need to update multiple data stores, and then of course, do it real time.
Subsequent scenarios may involve transformation of data to cater to the semantics and the idiosyncrasies of the destination systems.  
You will come across entities or their attributes that does not have an equivalent entity on the destination. You will also come across Need to have some mandatory entities created in the destination store, when the source has nothing equivalent to send across.
Further there can be workflows triggered based on incoming data, and of course the workflow themselves may enable data changes across multiple systems

 

So what, why should I be concerned?

Well unfortunately or fortunately, I have had the opportunity to work on programs which involved Integration between such disparate systems.
We have had successes and failures along the way, with a horde of factors contributing to those results.
It makes sense to reflect on what I learnt and summarize for future.

I will probably take a couple of weeks… to gather my thoughts.

nuggets from Paulo Coelho

When we sense that the time has come for a change, we begin -- unconsciously -- to run the tape again, to view every defeat we have experienced until then.        "And, of course, as we grow older, our number of difficult moments grows larger.  But, at the same time, experience provides us with better means of overcoming those defeats, and of finding the path that allows us to go forward.  We have to play that second tape on our mental VCR, too. "If we only watch the tape of our defeats, we become paralyzed.  If we only watch the tape of our successes, we wind up thinking we are wiser than we really are. "We need both of those tapes."

5 essential tasks of a PM

1. Satisfy the Customer

2. Meet the Requirements

3. Deliver on Time

4. Deliver within budget

5. Keep the team Happy

Schedule vs Quality

I had an experience this weekend, that is an important lesson

Here's what happened
My vehicle service was due for sometime, and since I had to travel to Mysore over the weekend.
I decided to get the vehicle serviced on friday.I gave the vehicle (with no major complaints) at the service center for a regular service witch is done every 5k kms, I have been doing this for the last 4 yrs at the same service stn.following a similar routine i called up the center at around 5pm asking about the status of the vehicle to indicate the i would be there in an hour to pick the same

On this fateful day, the supervisor at the other end, responded that there was some nagging problem and he had not yet been able to diagnose the cause, and requested me if i could pick the vehicle the next day evening after he had it fixed. That news was something i had not expected, so I shot back on the phone, telling, I really need to go to mysore this weekend, and If the problem was not very major, I would still like to take the vehicle for the weekend and give it again to fix the problem, sometime mid of next week.

The Novice Supervisor, who was slightly hesitant agreed to my request and the got the vehicle ready in the next hour and promptly delivered to me the same day evening. I picked up the vehicle, and the alignment of the wheel seemed slightly imperfect, the steering wheel showed a tendency to veer towards the left slightly. I ignored that and decided that i would give it back for service sometime later and get it fixed.

The next day I started my trip to Mysore, with my family, but now the steering problem started intensifying
as i got farther away from home. thats when we decided to turn back and return home, my family did travel to mys. in the public transport bus and i headed straight back to the service station

I happened to meet one of his more experienced peers during the second visit, and he commented, "I had advised him not deliver the vehicle if he was not confident but the customer insisted that he wanted it for the weekend and he unwillingly obliged"

As i write this piece, the above comment from that experienced supervisior, keeps ringing in my ears. How often have i been in such situations in my own profession, in fact on both sides of the fence

There have been umpteen no. of times when we have unwillingly delivered to customers, and got it back indicating that there is major flaw (which we were well aware of) and yet times i have also requested delivery of product from my team, and they have obliged unwillingly.

Looking back after today's experience, I realise that i happen to be somewhere between the Novice and expereinced supervisor, and hope today's episode will keep reminding me of the importance of Throughness of the product as against the deadline

SCAMMPERR - Look for Alternatives

Substitute, Combine, Adapt, Magnify, Modify, Put to other use

Eliminate, Re-arrange, Reverse

 

PM Skillset

The following are essential skills for Project management with Data, People and Things

As identified by Alex Brown PMP

 

Skills with Data

Synthesizing, Coordinating, Innovating, Analyzing, Compiling, Computing, Copying, Comparing

 

Skills with People

Mentoring, Negotiating, Instructing, Supervising, Persuading, Speaking, Serving, Helping

 

Skills with Things

Setting Up, Precision working, Operating-controlling, Manipulating, Tending, Feeding-Off bearing, Handling