Not every feature is a “must to have” to improve web usability

Changes requests keep on filling up the spreadsheet.  For every session, we went through each requirement with the Customer to understand what exactly is required and how it may impact the solution.

Some requests are just ‘nice-to-have’ features, some are unable to be supported by the solution due to the initial system requirements being designed for the solution.  The application was merely just an online shipment tracker tool but now it has almost included order management, procurement, reports and now on to add on marketing functions!  We need to revamp the existing solution’s architecture to cater the new technologies to support these features.

We need to understand the ‘real’ reason for each feature and do they really have critical impact to the Operations/business?  These “good-to-have” features may assist to improve the usability but we need to understand the business flows and to see if these features really assist/improve the end users’ experience based on the works they are using with the application and it may slow down the application and even affects the system performance.

Next step, we are to evaluate the system performance again after all the approved changes have been implemented to see if there is any further improvements and to consider the going-forward plans to enhance the application.  We are using the same evaluation plan, web stress testing to capture the measurements for comparsion and assessment with the Application and Infastructure teams.

Stakeholders’ Buy-in To the New Project Plan

We have revised the project plan and the project is going to be delayed by 3 months, with the reasons identified that are causing the delay.  This had brought out to the Steering Committee (or do we really have a Steering Committee in the first place???).  The reasons we have are:

1. Resources that are to be involved with this project B were actively involved in earlier project A that conflicts with the activities that were being planned.
2. The project A was on high priority list and it is a dependency to Project B.  We have to complete project A before we can start to engage with the Customer to work on Project B.
3. The resources involved in Project A acquire the same knowledge that we need to work on Project B.

During last Thursday kickoff meeting, the revised time line was shown and  had presented to them the information for the delay.  Indeed this did not please the stakeholders in the meeting but the project team had done what they had to mitigate the risks and ultimately we tried all possibilities and this was the only way to move the project forward.  The action is now leave to the Business Manager to inform the Customer of this delay and alternatively what we are trying to do to see if we can speed up or agree on the iterative releases of the solution  at the end of the feasibility study phase (refer to link for information on DSDM -http://www.codeproject.com/KB/architecture/dsdm.aspx)

The next step we need to do to get the stakeholders’ agreement that we are working towards the new go-live date and to inform the Customer about this so that all of us are aligned and start to plan the remaining activities to be involved for each party.

Validaty period for the costings for the Infastructure proposal

This has never come to my mind that vendors will keeps on changing their quotations for the hardware, software and the service support costings due to the competitive economy nowadays.

We has reviewed a previous proposal that was about 2 months old and we got the revised costing from the vendors and had to update it for our Account Manager for next week’s workshop.  The initial proposal was given to the Customer 2 months ago but there was no update from the Customer on the moving forward plan on how to proceed with the proposal.  There are lots of changes happened for the last 2 months and so was the pricing quoted by our vendors as we just gone through the review today.

No doubt, the Account Manager does not accept the changes in the costing, much to the surprise to hear from her that the Customer was currently evaluating the initial copy.  To our surprise, we had never knew the Customer was looking at it and we cannot absorb the additional costs for the hardware since we are outsourcing to external vendor, not internally.  On second thoughts we did not explain clearly in the proposal of the validity of the pricings we had quoted in the document as to set the expectations and possible changes as the evaluation has taken place so that immediate attention is placed to get the review done and decision is being made with the Customer.

As so, I have taken notice to include a clause at the last page of the proposal to indicate the validity period of the pricings that we had quoted as to avoid future misunderstanding.   What a lesson I had learnt today!

I have moved on to Program management….is it?

First day back to work from vacation, I have received a ’surprise’ email from our Global Account Manager to understand the new project from our EMEA counterpart.

It sounds strange to me why I have to be involved as we have an EMEA IT team supporting this account over there.  Perhaps we are really lack of a Global IT Head to communicate and align the solutions for this account as every region will work on their own ways and ‘duplicate’ systems around the globe.  This is not the direction that our Global account wants to have, and I do see the need to have a Global IT head to lead all regions on this vision.

Now I have to play this role, ensures all regions are aligned and promote ‘reuseability’ among regions, this is a very huge responsiblitye I need to manage to fulfill the vision.  The first thing I need to do is to gather all the existing applications’ inventory for each country/region to see what are the solutions we had can be reused for other countries or future RFQ enquiries.

Hope I can work this out……