The Design components of PMFW

In previous two posts I had discussed about the methodology and schedule plan of PMFW. Since, the requirement and reporting of each vertical has its own scope, and we also needed Birdseye view of every thing happening at program level. In analysis phase we modeled each system as individual unit. The classification was based on method of data collection and out-put expected from individual business vertical. Quite aliened with basic function of Program and Performance Management, in the picture below you might find some alien jargons.

Here is list of demystifications to make your life easy.

People Info System: Operational Metrics related with people on work, like attendance, schedule planning, Attrition, etc.

Ops Info system: It covers the operational tracking and reporting requirements at Program level.

TM Info system: TM stands for Transaction Monitoring system, don’t mistake it with financial transactions it’s about the accuracy and standardization in customer communication.

QoS info system: Since, the program deals with end user (sorry can’t talk more then that, Info security policy) we had to track and measure the satisfaction level of end user for our services/products. So QoS is meant for tracking the customer experience and takes feedback and inputs for improvements in product/service offered from our site. QoS stands for Quality of Service.

Tracker Data: In daily operational routine, there would be many details that are collected and maintained as and when needed. They may not count significant in terms of data amount collected; however, per my experience these are crucial indicators of operational efficiency. So we decided to scrap all the notepads and excel worksheets with some designated predefined way of data collection through ticketing method.

Agent Info system: Well! all I can tell you about this is that it’s a one view system to report the efficiency of each one working in our program.

The first five systems have data inputs and storage methods where as the Agent info system is parasite model running on other five basically it deals with statistical measurements and scorecards that a manager needs to look at every day.

The development plan!

Since, PMFW closely deals with a highly dynamic system, where end user requirements and measurement changes are liable to happen in short interval the development plan had to have a Rapid Application theory. However, we had to also ensure that system stands perfect and maintains the standards that were generated from manual excel working models. We had to choose a path that was not slow as waterfall method and still had the same accuracy level. We decided to go ahead with combination of RAD and accommodated few faces of SLCD. The development and testing were clubbed process running parallel. Since, it was not software development process backed with professional testing team; we decided to use automated scenarios and real-time user testing. The developer had to test the system after development for any technical foes and end users were appointed as beta tester. Until now non of the end user have been able to report a fatal of critical error, but still I am keeping my fingers crossed because it might be the overwhelming GUI that might have blotted their analytical approach! (May god! if my speculation is just a myth.)

Here is the plan! (Dates removed, but we are very much in development-testing face).

Program Management Framework

Hi!

Perhaps, it’s bit late to create B-log about Program Management Framework activity at APACMS (Code name); however, I couldn’t resist the temptation and decided to schedule some free time for b-logging the story.

Program Management Framework is activity intended to streamline the three verticals people, performance, and quality. The system architect is set of interlinked process flow that would be used independently and collectively for better a process control. Perhaps, defining it in terms of end user “It’s a integrated information system to track, measure, and report all operational, non-operational Metrics, through streamlined the data collection, automated information access, and statistical reporting system.”

The conceptual module of PMFW.

As described in picture above we are trying to integrate a system that can collect, store, analyze and report the outcomes in statistical measurements, it’s seemly understandable that PMFW should be flexible enough to accommodate any changes in system dynamic of any three verticals. That’s where the challenge of appropriate technology selection comes into the picture; we decided to go with RAD tool which was familiar to end users like MS Access and Visual Studio Tools for Office System. Before, locking into PMFW all these three verticals had end user reporting and data collection depended on Excel worksheets, apart from few exceptions where centralized business information systems were used. So we have two challenges, getting people used to the new way and accommodating requirements without bringing fundamental changes to system.