Friday, September 18, 2015

Friday Freeday - Download FREE Project Management Template



The best way to learn to teach. On the same theme, from this Friday onwards, I will start sharing the knowledge I have gained over the years from the 16 years of software industry experience. Since I have spent close to 11 years in healthcare alone, some of my sharing may be towards the healthcare vertical. But nevertheless, the core software development & software project management is definitely my passion.



To kick start this Friday Freeday effort:
Please view the and download the most important part of any project.
The project management plan template!
Posted by at 43 comments:

Wednesday, November 26, 2014

ETM, the new ATM for Healthcare - Health Disrupt (Part 1)




Article cover image
G Saravanan

G Saravanan

Enterprise Architect at Centium Software (g@centiumsoft.com)
Edit post

ETM, the new ATM for Healthcare - Health Disrupt (Part 1)

Nov 26 2014
ETM, the new ATM for Healthcare - Part 1
Consider the following scenario:
Scenario 1:
You have cash in Bank A. Bank A has been your preffered bank for many years.
One day when you were traveling out of town, you ran out of cash and had to take cash out, Bank's A ATM machine was not available. What do you do? Naturally you would look for another bank's ATM, in this case Bank B and take out your cash, for a small nominal fee.
Scenario 2:
Consider yourself applying for a bank loan for a property purchase. The bank which you are applying to, will be able to access a centralized repository where all current loan, payment history, current financial health of the applicant, and all other financial information of the applicant is listed, a summary of all bank' data. With such a information, the bank is able to review and decide if the applicant is eligible to get the loan.
Consider both the scenarios above to be applied patient's healthcare record, in this case, electronic healthcare record (EHR).
Scenario 1 in EHR:
You have been visiting Hospital A for many years, and have all medical records there, in electronic format.One day when you were travelling out of town, you fell sick and had to visit Hospital B. After many tests, Hospital B can't find anything wrong with you and they require all your previous medical records. Using a ETM 
(EHR Teller Machine), you simply go to this machine, pay a nominal fee and print all your medical records needed and pass it to doctor in Hospital B.
Scenario 2 in EHR:
Consider yourself applying for a life insurance policy. Of course you will be sent for a medical examination. But on top of this, with the "ETM central Network of data", where all records from across all health institutions are available for the insurance companies to view and summarize, and further decide to approve your insurance application or not.
Both the scenarios are not impossible to achieve. What is even more important is that, we got to stop talking about Application to Application integration, and start talking about Application to the "EHR Teller Machine Cloud" integration. With this, regardless of where we are, what "device" or software is being used, we will be 
able to access the medical records seamlessly.
The easiest way to do this, is to bring the ATM machine and ATM network model into EHR model. If we continue to hope that all EMR/EHR/HIS to one day be integrated, it is unlikely to happen. All we need is these data to 
be pumped into a central repository, which then be printed out in a ATM like machine called ETM. Yes, it re-introduces paper into the Medical Records, but it ensures sharing of medical records. There might be some who wonders, why re-introduce paper when we have Apple launching Healthkit with its Apple Watch, 
Microsoft having Healthvault, Jawbone's UP etc. But when it comes to healthcare, consumers (patients) behavior is different, adoption rate is always low. Refer:http://www.forbes.com/sites/zinamoukheiber/2014/11/24/i- asked-20000-doctors-about-fitbit-and-apples-healthkit-and-heres-the-answer/
Health technology adoption only happens during a trauma or on need basis. Meaning, only when accident occurs, and only when the victim's medical record is critically needed, people tend to think about the importance of getting victim's medical record to provide a wholesome treatment. And this works out well for the ATM like model. (think of petrol kiosk (gas station) when you run out of petrol/gas & think of ATM machines when you run out of cash on hand.)
Continue to hope for pure 100% App to App medical records integration is a lengthy process. Imagine the jump from 2G telco networks to 3G, we had 2.5G, or better known as GPRS technology. (Which exsits till now).
Consider this ETM in the similiar way. Next article in this series will include the technical view point and feasibility of getting this done - coming soon.


Posted by at 2 comments:

Wednesday, November 19, 2014

Un/Standardization in Healthcare Informatics


Article cover image

G Saravanan

G Saravanan

Enterprise Architect at Centium Software (g@centiumsoft.com)

Un/Standardization in Healthcare Informatics

Nov 19 2014
The importance of standardization in an industry, cannot be under stated, without standards, we would not be having many of the stuffs we enjoy now. And it is the lack of standardization which is holding back Healthcare Informatics from exploding.
Make no mistake, I am not saying that healthcare informatics lack in standards, no it does not. But the process of implementation and educating the industry on what needs to be implemented and complied with is what is lacking. Take HISA (Health informatics Service Architecture) for example, its a worldwide ISO standard, (ISO 12967), its a great standard, it details out the description, planning and development of new health information systems architecture; the integration of existing electronic health systems, both intra- and inter-organizationally; using architecture that integrates common data and business logic into middleware; which is then made available throughout whole information systems.
3 main parts:
- Enterprise Viewpoint
-Information Viewpoint
- Computational Viewpoint
The only issue with HISA, is that it is too generic, and not specific, meaning, it is not meant for someone to just "pick it up" and start implementing within 
healthcare sector. Its almost right to say that its the "TOGAF standards" for Healthcare Informatics. TOGAF as most people know is too generic and often 
requires extensive amount of tailoring, experience and requires other supporting standard like ITIL, CMMI, Agile, PMI and others to go along. Same in 
healthcare informatics. We should be having the following list as the core standards on top of HISA (being the horizontal standard):
- HL7 for Clinical Application to Application protocol
- DICOM for Radiology Application integration
- ASTM / LOINC - for Lab Application integration
- CCD - as for Medical Records Format
- ICD 9/10 - for Diease Code
- MIMS - for Drug Code
- SNOMED CT - Comprehensive clinical health terminology
- EN 13606 - Electronic Health Record Communication
- IHTSDO - International Health Terminology Standards Development Organisation (IHTSDO)
The above set of standards, should be the recipe for any planning, development, deployment, and change management of healthcare projects, particularly 
focusing on medical records, hospital information systems, EHR and EMR, integration or upgrading.
Note:
CCD (Continuity of Care Document) is by ASTM & HL7
CCR + CDA = CCD (Something like this)
Paving path towards a Healthcare Enterprise Architecture & Technology [HEAT] standard...
Posted by at No comments:

Sunday, March 17, 2013

Humans ~ The Weakest Link



Humans ~ The Weakest Link
Humans are often the weakest link in the software engineering projects chain of processes. Evident in various terms invented to describe them, funny and both educational, but causes serious damage to projects and in some cases, even to companies:


  • PEBKAC ( http://en.wikipedia.org/wiki/User_error#PEBKAC )
    • Problem Exists Between the Keyboard And Chair
    • Classic description of human errors
    • n 2006, Intel began running a number of PEBKAC web-based advertisements[12] to promote its vPro platform!

  • ID10T ( http://en.wikipedia.org/wiki/User_error#ID-10-T_Error)
    • Straight way of calling the user as an "idiot"
    • Usually used between computers technicians to describe the user - for future reference
    • The Navy pronounces ID10T as "Eye Dee Ten Tango".
    • The Army pronounces 1D10T as "One Delta Ten Tango".




  • Layer 8 ( http://en.wikipedia.org/wiki/Layer_8 ) 
    • Much more elegant way of describing the user issue.
    • While the standard OSI layer as 7 layer (Applications being the 7th), the 8th Layer here is referred as the User layer. So, if we say that we've got a problem with the 8th layer, it is understood that its a user issue and NOT a software issue.
  • RTFM (http://en.wikipedia.org/wiki/RTFM)
    • "Read The Fucking Manual" This is a classic one, while this does not describe that its a user issue, these words are used to tell off the user to read the supplied manual of a software/hardware first, before asking any further questions.
    • Some history: http://knowyourmeme.com/memes/rtfm
    • Many more variations of this RTFM, as follows (from Wikipedia):
        •  
      • Encouraging the reading of the manual or other background information
        • RTBM ("read the bloody manual") (In some countries, e.g., the UK and Australia, this is a fractionally more polite alternative with identical meaning[9])
        • RTFA ("read the fucking/featured article"—common on news forums such as Fark.com[10] and Slashdot, where using "TFA" instead of "the article" has become a meme)
        • RTFE ("read the fucking e-mail")
        • RTFC ("read the fucking code" [also "reboot the fucking computer" or "read the fucking card"])
        • RTFSC ("read the fucking source code")
        • RTFSM ("read the fucking SWIFT message")
        • RTFQ ("read the fucking question")
        • RTFFAQ ("read the fucking frequently asked questions")
        • UTFH ("use the fucking help")
        • UTSL ("use the source, Luke", a play on the famous Star Wars quote, "Use the Force, Luke", referring to freely available source code)
        • RTFI ("read the flaming instructions")
        • RTFB ("read the fucking brief" common in advertising, design, photography)
        • RTFP ("read the fucking plan" common in construction, engineering, stage design)
      • Encouraging the use of at least a basic search
        • UTFG ("Use the fucking Google")
        • GIYF ("Google is your friend") ("Google it yourself fucker")
        • JFGI ("just fucking Google it")
        • LMGTFY ("let me google that for you") The basis for the website lmgtfy.com
        • JFWI ("just fucking Wiki it")
        • JGIYN ("just Google it, you noob")
        • STFG "search the fucking Google" (the initials are consonant with STFU)
        • STFW ("search the fucking Web") (the initials are consonant with STFU)
        • WIDGI ("when in doubt, Google it"—also occasionally "WIDGIT")

Posted by at No comments:
Labels: , ,

Monday, March 11, 2013

The Myth called Software Requirements!


By : G.Saravanan

The Myth called Software Requirements!

1. Can there ever be a complete set of requirements?
  • Answer would be NO, there is no such thing as a complete requirements.

2. So, if the answer is NO, how can we build a complete software?
  • The Answer is NO, we can never build a 100% customer satisfying software.

3. So, if the answer is NO, how can we improve it?
  • The Answer is in the question - We can only improve it!


In case you are wondering how can that be, when we have all the tools in the world to create and manage requirements, think about it again. How many types of requirements do we have nowdays - generally speaking, there are 2 - Functional and Non-Functional.



Most tools and techniques are only geared towards the functional requirements. How about the non-functional requirements? In case you are wondering what is the basic set of Non-Functional requirements which a software requirements should cover, we have an ISO standard for this. Its called ISO/IEC 9126 - Refer to the Quality Metric, there are 4 Metrics all together.

The Quality Metric says the following: ( http://en.wikipedia.org/wiki/ISO/IEC_9126 )
  1. Functionality
  2. Reliability
  3. Usability
  4. Efficiency
  5. Maintainability
  6. Portability
The general list of Non-Functional is much wider (scary as well). The question is How are we supposed to document/model/communicate this and get the confirmation from the customers?
Be it documenting is upfront in a SRS (for Waterfall lovers) or as a story board (for Agile lovers), what is the solution?



Posted by at 4 comments:

Sunday, March 10, 2013

The Motorola Method - Using Quickie to Manage Software Team

Managing a team is already challenging enough, now managing a distributed is a bigger challenge!

Long time ago, one of my friend told me something which stuck in my mind like forever. He said that you can manage 100 computers, but try to manage 10 people - you might just give up! Its been more than 14 years since he said that, and I couldn't agree more...

What I am about to share here is called as a Quickie, and what I have been using to manage my geographically (often, around the globe) distributed software development and deployment team. This method was taught to me by my first Project Manager in India. It proven to be one of the most effective way to manage my team, regardless of where they are, which time zone, what role they play. I was able to use this method, to get updates from around the world, use the information to understand the challenges faced, and mobilize solutions and deliver projects, with most of the miscommunication problems resolved.

Now, managing a team is already challenging enough, managing a distributed is a bigger challenge, and this practice started in 2000, when I began my career at Motorola's software excellence center in Bangalore India, then in Schaumburg, IL, and back to Malaysia, when it all began for me.

This is going to sound funny, but the report is called a "Quickie". This is probably because of the nature of the report, which is meant to be easy and fast to be written. The goal of the report is to have a structured method of reporting your day's or week's work status, as well as let the audience know of your next plan.

How does a Quickie work?

The method is fairly simple (sometimes too simple). We have 4 lights. Red, Orange, Green and Blue. (The original version had 3 lights, I improvised, added the blue light).

Details of the Quickie:


  1. Format
    • Red Items (Blocking Issues), stands for issues in your work, which has totally stoped you from achieving and completing your planned work of the day (the previous day's Blue Items).
    • Orange items (Potential Issues), stands for potential issues at work, which may or may not be an actual issue yet, but either way, you think that this potentially will disrupt your work and will become a Red Items in few days time.
    • Green Items (Achievements), stands for what work was accomplished for the day. Ideally speaking, these should be what was written as Blue Items on the previous day.
    • Blue Items (Plan for next week/day), by now you should know that this is where you write on what are your plans for the next day.
    • This typically is typed out in a simple mail, with the subject of the mail in this format: W52-Quickies, the W number refers to the number of the week (a typical year has 52 weeks).
  2. Frequency
    • I used to request the Quickie from my engineers, Project Leads, Architects, Project Managers on weekly basis, with the above subject line, but over time I have come to realized that a Quickie is much more effective to be done on a daily basis due to the mammoth data which needs to be compiled if done on weekly. 
  3. How it works
    • Hence the goal is for everyone in your team to complete a Quickie on daily basis and send it to your before 5pm (or end of your business hours).

Advantages:

Simple & Fast

  • Miscommunication or worse no-communication is one of the major mistakes done is most software projects. In most cases, by the time the issue is caught or brought to surface, damage would probably been done already. Hence the challenge here is to detect the issues (Red Items) or possible issues (Orange Items) as early as possible. I can't think of a faster method for anyone to get status from a 100 man team, and to identify all of the major statuses, whcih needs attention.
    • Red and Orange Items
      • Now, most people may argue that isn't it obvious that when you have an issue, you would point it out, and ask for help? Now, that is not the case in most software projects which I have seen:
      • Some engineers tend to think that if they highlight their difficulty in getting the job done, they are incapable. (not realizing that suffering in silence gives a major impact to the project progress). Hence a protocol is established that any issues faced (technical or non-technical like lack of documentation, API not available, laptop malfunction, server too busy, etc.) are highlighted by the end of the day, in the Red Items section, failing which, it becomes the responsibility of the Project Manager to question the delay caused by the engineer, for an issue which was not highlight before, when delays are detected.
      • Some engineers are just too proud to let go of their tasks to others. They feel that once a task has been assigned, they and only they alone should solve the tasks, no matter how long it takes (even if the project suffers). 
      • The goal of the Red Items is for the Project Manager or Project Director to be able to receive probably hundreds of Quickie, and be able to browse through quickly, and identify the Red Items which are blocking the progress of the project on a daily basis.
      • Can you imagine how much time will be wasted by having a status meeting with 50 man team - 2 hours if you are lucky. Now, with something like Quickie, you will be get to read read status from 50 people in a structured manner within 10 minutes - at most.
      • Now, the Internal Service Level Agreement or SLA for a Project Manager should be to allocate resource or find a way to solve the Red Items of a team member by the next day, morning. Simply because when a team member has a Red Item issue, he or she simply can't continue working. Hence the faster the PM reacts and solve it, the smoother the project would be.
      • Now, for the Orange items, while it is not a major issue (yet), a Project Manager has to keep tabs on these items, as these are the possible Red Items within the next few days. So, again a SLA should be established as to by when a PM resolve all of the Orange Items in a project.
    • Green and Blue Items.
      • The Green Items and Blue Items are for monitoring. These are areas where you get to monitor the work progress of your engineers. Are they designing and developing according to your briefing few days ago. While these items may not be seem as critical as Red and Orange Items, it is vital to monitor these, specially for the Project Leads, Architects, Technical Leads or anyone who plans the technical work items for the engineer, and for those who are responsible for the final delivery of the work items. It is very common that some engineers tend to go off tangent, and goes unmonitored for days, and just imagine the time and cost impact for the rework once the deviation of scope or functionality is detected. Whereas with a Quickie, you get to monitor them on a daily basis.
      • Blue Items can also be used to plan for holiday - letting your PM and Management know of your plans OR actual next day, which you wont be in.Sometimes a leave may have been approved, but the Technical Lead Project Lead may not be aware that the engineer may not be around (they can't be checking the calendar of everyone, every day)
      • Empty Blue Items indicates that the engineer does not have any more work (and that he or she has completed all tasks as of today). While rare, this does happens, and there are times, when gone without monitoring, engineers may have a vacuum slot, where no tasks has been assigned, simply because the team does not have a tool to monitor the day to day activities - like Quickie!
      • A Quickie is also very useful, as not everyone may be available at the same time for a status meeting. Hence getting a status from everyone using the same format, is a great tool for project monitoring.

Disadvantages:

Too Simple & Too Fast

  • Yes, if there has been comments on the way I use Quickies, it would on the amount of details which goes into the Quickies. You see, the quickie is meant to be, well Quick, as short as possible, without the micro details, like how much of time has been spent on troubleshooting, who are the resources  which we have approached, what are the techniques used so far to troubleshoot it, and so on.
    • But on the other hand, my argument is that if we are supposed to write a 2 page essay every day or a 10 page every week, we simply wont. And that will eat into our productive hours, and also people will tend to drift off in their own ways of describing their statuses.
  • Too fast refers to some who have informed me that daily Quickies has too little updates, and sometimes repetitive updates on daily basis, as some work tasks, takes days, and only percentage of completion changes on daily basis. My answer - Good!
    • My view is, it is better to have a tool to communicate on daily basis, use few minutes to send out a status, then not having a method all together, and only to land in trouble when issues arises.
More to write, but will stop here, to get comments from all....

Posted by at 10 comments:
Subscribe to: Posts (Atom)