Posts tagged: system

Book reviews: The Effective Executive; It’s Not How Good You Are, It’s How Good You Want to Be; Liar’s Poker

By , December 10, 2011 3:02 am
The Effective Executive - Peter F. Drucker

The Effective Executive – Peter F. Drucker


A classic work by the father of modern management science, this book is the first to distinguish effectiveness from efficiency, and identify principles of management.

While named "The Effective Executive", the book does not only discuss management of subordinates, but also management and enhancing effectiveness of one’s self.

This book is pragmatic, authoritative, definitive, and compelling. The author gets to the points without unnecessary narration and defensive techniques usually found in management texts.

Despite being completed in 1966, the wisdom from the book is still relevant today, free of fads and jargons. This timeless book is to last. I give the book a full five star.

It's Not How Good You Are, It's How Good You Want to Be - Paul Arden

It’s Not How Good You Are, It’s How Good You Want to Be – Paul Arden


A powerful book, "It’s not how good you are, it’s how good you want to be" tells different stories from the experience of the author as a manager from his creative firm.

Each chapter starts with a short and acute mantra, accompanying stories, and morals behind the stories.

The language used in the book is heart-touching and persuasive. The stories are kept short and straight-forward while not any less inspiring.

The book is very well crafted with art works, illustration, brilliant use of colors, typography choice, and white spaces.

Overall, this is a good read for everyone, not only restricted in the creative industry. I give the book five star.

Liar's Poker - Michael Lewis

Liar’s Poker – Michael Lewis


Writing a review for "Liar’s Poker" was not an easy job for me due to the complexity of attitude and emotions I was going through during and after reading the book.

The book reflects an important stage in history of Wall Street – the road to glorious domination and subsequent demise of Salomon Brothers. The saga sets off two entities: the financial instrument (mortgage-backed securities) and its creators.

The complexity of emotions I mentioned arose from enjoying being entertained by the sharp wit of the author, mixed with a drive on a solemn quest to deduce applicable lessons from the experience. It’s easy to be entertained and then sneer about the jokes, but it’s tough how to move things forward post-illumination.

I’m curious what you will personally share after reading this book.

RMIT Vietnam Alumni System public version V2

By , February 9, 2009 2:47 pm

e-Learning should no longer stand alone

By , July 12, 2008 2:07 am

Since its development from 1979, e-learning has increasingly played an important role in training of many organizations.

Traditional classification of e-learning is categorization. Courses are put into common categories such as: business, soft skills, technology, social sciences

From Horizontal to Basket

However, categorization gradually fall shorts in the need of real organizational training. One professional should have a combination of knowledge and skills across various disciplines. For example, a Project Manager should have Project Management skills, Leadership, Technical skills, Interpersonal and Communication skills, Client Management skills, Time Management skill, Coaching skill and so on. All these skills belong to different categories like Management, Soft Skills, Accounting, Technology. Any organization may want to standardize the training “basket” for each position. A basket contains courses/programs/articles that one person should acquire in order to perform a role.

Learning Basket

then moves on to integration

Now, let’s take a look at the system as a whole. Training is one important part of an organization. Because it is important, it needs tracking and measurement. Key Performance Indicators can be used on Training as on any other departments.

Then an idea crossed my mind: the computer can be taught to ‘know’ what the employees need to learn in order to

  • Follow their career plans
  • Satisfy the organization KPI

e-learning should no longer stand alone, it should be integrated into other systems instead.

What technologies are available?

Can Portlet do that? Just a suggestion. I’m leaving this to the experts here.


By , July 3, 2008 1:49 am

Simplicity in Design, with examples from Apple & Google

Source: Stuff that happens, Simplicity

Managing a Limitation of a system

By , January 31, 2008 3:33 pm

A limitation is not a defect

A defect is defined as non-conformance to requirements.

A limitation of a system is something a system does not accomplish, either due to technology not being supported, time constraint budget limit, or nature of business model.

Ideally, limitations should not exist in a system. However, in engineering discipline, certain limitations are accepted. This article seeks to explore ways to manage a limitation.

Scenario: a simplified example of a Customer Relationship Management System

Business domain level

Simplified Customer Relationship Management System

An Opportunity is created from a Contact when Sales representative has approached and make a proposal to that Contact. If an Opportunity encounters difficulty, it is converted to a Lead and requires more attention. If the Opportunity is done successfully, it becomes a Contract and Price is calculated. A Lead, if done successfully, can become an Opportunity when meeting certain criteria or become a Contract. If a Lead fails, it is dismissed.

System level

The object is a Transaction. A Transaction has 3 statuses: Opportunity, Lead, or Contract.

System allows changing status of Transactions.

An issue is raised: Does the system allow changing from Contract to Opportunity? Does the system allow changing from Contract to Lead?

The impact could be huge. The system must handle Price and Invoices. This concern is accurate.

Back to Business domain level

However, back to Business level, the situation may not affect the operation at all. In reality, when a Contract is signed, it does not have to be switched back to Opportunity or Lead. The customer may not even care for this scenario.

What do we (the project development team) do to address this gap?

Widely accepted principles of system development and project management

To address the issue, let’s get back to principles of project management

  • The system should be able to satisfy customer requirements.
  • The system should be able to handle exceptional cases.
  • The system should be within budget and time frame with given resources.
  • 80/20 rule applies. In certain cases, 80% efforts are spent for functions that users use only 20% the time.

How different roles view a limitation

A natural engineering approach of this gap is to restrict changing status of a Transaction from Contract to Opportunity.

However, when the proposal is put on the table, the chance maybe that it is not accepted. Firstly, the client doesn’t want a restriction in the system. Next, the client doesn’t want the development team to spend much efforts and time on a functionality that will not be used frequently.

This leaves a limitation in the system: it still allows converting Transaction status from Contract to Opportunity or Lead, but it won’t fix the Price and Invoice. This limitation leaves it to the hand of user to manage data themselves.

Manage a limitation from different perspectives

  • System Analyst: this limitation is put in Supplementary Information section in a document.
  • Technical Writer: this limitation is noted in User Manual.
  • Business Consultant: communicate with client on this issue.
  • If any issue arises, it is to be escalated to the Project Manager.

GUI Design for Enterprise Systems

By , January 23, 2008 8:04 pm

The Dilemma

When designing screens for enterprise systems, I frequently face an issue. There are too many fields to present for a user to complete an action (i.e. manage an order transaction). In terms of cohesion, since these fields serve one purpose, they should be put in one screen. But again, too many!

Too many of them clustering in one screen makes it look like a mess with texts, numbers and boxes. Not nice at all!

New design trends pushes this even further

The new design standard introduces alternating colored grids, text boxes with strong borders. All of these increase to size of elements, thus will make the screen narrower.

So we face a dilemma: should we put all relating fields in one screen, or break an action into multiple screens?

All in one screen or break down to multiple screens?

Put all in one screen
Break the information into multiple screens?

What’s your Focus?

There are a couple of things you can do:

  • Review GUI Design Guidelines
  • Review a high level document (i.e. Vision) to determine what the system is for and what it should look like in general
  • Create different prototypes and propose them to the customers

The most important factors

Some factors to look into when composing your own solutions:

Number of clicks

Because user’s interaction with system is done chiefly through mouse motions, number of clicks is considered one of the most important factor of GUI design.

Most of the cases, my experience is that with a little twist in design, number of clicks can be reduced from 3 to 2. Not so frequently it can be cut down dramatically. 1 click seems trivial. However, a user may perform that action a thousand times per day, thus makes it worth the effort.

Efforts users have to spend to learn how to use the system

If a screen has too many fields, it would be confusing for first-time users to know how to locate information.

If it takes quite some screens to accomplish a task, it would be confusing for first-time users.

In the long run, the first solution would prove to be better when user has memorized the location of information sections.

Panorama Theme by Themocracy