Prince2 - hands on how to...

Here is the order to which a project can be managed using the PRINCE2 process model:

1. The Programme Management developed a project charter, or has defined preliminary guidelines and goals for the project. This information will be used in SU (Starting Up a Project) to assign a PM, appoint a project team and to prepare project documentation for the project board to terminate/authorise the progression of the project to the next phase.

2. The project board will reject/authorise the project to progress to the initiation stage after reviewing the project brief & initiation stage plan for the project, as well as allocating resources for the project initiation phase. The project goes into the next phase if project board approves the initiation phase.

2a. If the project board rejects the team's proposed initiation stage plan, the process is restarted again.

2b. If the project board approves the team's proposed initiation plan, the project moves to the IP stage.

3. In the project initiation phase, the project team will plan the quality and develop an overall plan for the project. More importantly the Business Case, PID (Project Initiation Document), Project Controls and Plan for the next stage are created for the project. These are submitted to the project board for assessment and approval must be gained to proceed to the next stage.

3a. If the project board rejects the project team's proposed next stage plan, the process is restarted again.

3b. If the Project board approved the plan for the next stage, the project is now moving into a 'doing' phase where work package definitions are defined. Line managers are usually involved at this stage to give consultation on specific details on work packages.

3c. The Business Case, PID and next stage plan are reviewed by the project board that assesses if the project should continue by evaluating the viability of the updated Business Case. In addition, the next stage plan is reviewed and approved before the project can proceed to the next phase. Should the project board decide that the Business Case for the project is no longer viable; the project shall proceed to CP (Closing a Project) prematurely.

4. During CS (Controlling a Stage), the project manager and the line manager agreed on the specification and expected quality of the work package. It is then the responsibility of the line manager to coordinate his/her resources to get the work completed to the quality and specification of the work package. In some cases line managers can be contacts from external parties to the project team or project organisation.

5. Depending on the size of the work package, checkpoints may be used to monitor the progress of the work package.

6. Once the work package is completed, the completed work package is handed to the project manager who should get verification that the completed work package is consistent with the standard specified in the work package definition.

6a. If the work package fail to satisfy the quality or specification specified on the work package definition, the project manager can reject the package and the whole process is restarted again.

7. Step 4 to step 6 is repeated for all work packages planned to be delivered during the current stage. Multiple work packages can be initiated concurrently and with multiple line managers/3rd-parties providers.

8. Project controls are in place to highlight to the project manager any project issues and risks that were identified and/or realised during the current stage. The project manager should seek ad-hoc recommendation from the project board (through DP-Directing a Project) if realised issues/risks threatens the overall project.

9. Should the project board decided, after assessing the business case, that the project is no longer viable, the project shall proceed to close (CP-Closing a Project) prematurely.

10. The project board can give ad-hoc feedback and/or recommendation, in respond to the realised issues/risks, to the project manager to be implemented in the current phase.

11. During the implementation of the current phase, the project manager may realise that targets set within the current stage plan may not be realised as a result of unforeseeable internal and/or external issues. In this case the project manager should update all relevant project documentation and prepare an exception plan taking into account of the realised issue/s and its effect to the current stage.

12. The exception plan is presented to the project board for review and recommendation. The project board can either reject or approve the submitted exception plan, taking into the new plan's effect on the viability of the business case for the project.

13. The decision to reject or to approve the submitted exception plan is communicated to the project manager as feedback.

13a. If the project board rejected the initial exception plan, the project manager should submit subsequent exception plan incorporating project board's recommendation.

14. The project manager should inform project board if exception plan is un-workable with project board's recommendation, as ad-hoc feedback.

14a. If the project board, after evaluation, decided that the business case for the project is no longer viable, the project moves to CP (Closing a Project) to be closed prematurely.

15. When the current stage is approaching an end, the project manager should update all relevant project documentations;

15a. If the current stage is not the last stage, prepare project plan for the next stage.

15b. If the current stage is the last stage, initiate a notification of project end and proceed to CP (Closing a Project) to formally close the project.

16. The next stage plan is submitted to the project board for review.

17. The project board reviews the submitted next stage plan and assessing the viability of the business case to either approves or rejects the submitted next stage plan.

17a. If the project board rejects the submitted next stage plan, the project manager should submit subsequent next stage plan incorporating project board's recommendation.

18. Steps 3b to steps 17 should be repeated for all subsequent project stages.

19. Follow on from step 15b: The project manager should ensure that the project delivered all products, and in the quality standard specified in project specification documents. In addition the project manager should ensure users approved and signed off all delivered products and all post project responsibilities allocated. Project board should then approve the closure of the project by handing over responsibility of the product to users and release all resources assigned to the project. In addition the project board should inform corporate management of the project's closure.

My Selected Journey Photos

End of Models

Sixty years ago, digital computers made information readable. Twenty years ago, the Internet made it reachable. Ten years ago, the first search engine crawlers made it a single database. Now search engines are sifting through the most measured age in history, treating this massive corpus as a laboratory of the human condition. They are the children of the Petabyte Age.

The Petabyte Age is different because more is different. Kilobytes were stored on floppy disks. Megabytes were stored on hard disks. Terabytes were stored in disk arrays. Petabytes are stored in the cloud. As we moved along that progression, we went from the folder analogy to the file cabinet analogy to the library analogy to — well, at petabytes we ran out of organizational analogies. Now they call it clouds.

The Petabyte Age is now challenging all boundaries. The biggest and the scariest victim of the Petabyte age is Theory. Anderson in his book The End of Theory: The Data Deluge Makes the Scientific Method Obsolete sums it up: "This is a world where massive amounts of data and applied mathematics replace every other tool that might be brought to bear. Out with every theory of human behavior, from linguistics to sociology. Forget taxonomy, ontology, and psychology. Who knows why people do what they do? The point is they do it, and we can track and measure it with unprecedented fidelity. With enough data, the numbers speak for themselves."

The often quoted phrase, "Essentially, all models are wrong, but some are useful", is attributed to George Box one of the most influential statisticians of the 20th century and a pioneer in the areas of quality control, time series analysis, design of experiments and Bayesian inference. It now seems a rude reality as all modeling will be challenged by the statistic spewing Cloud of the Petabyte Age.

The royal road would be to demonstrate that models are crucial to science, which would be grounds for thinking that they are logically necessary. Timmer takes the short cut on pragmatic grounds: models have utility, regardless of their truth or falsity. Models, so to speak, make the scientific establishment go around.

Indian IT - how it all started

The Indian software industry dates back to the days before 1990. At that time the industry was tiny - it employed fewer than 30,000 people - but they were employed by or organised in many small firms. There were no satellite communications, no Internet, and the only way of exporting software was export of coders. Personal computers were only ten years old; there were hundreds of programmers who had written BASIC, COBOL and Fortran programmes for IBM mainframes.
India lagged behind the world which was converting to PCs and packaged programmes. So when someone in America wanted their mainframes configured or new programmes to be written for them, they could find such outdated but valuable skills in India. The programmers were clustered around the handful of government laboratories and big businesses. They began to form small outfits and export people - what came to be known as body-shopping.
The business was similar to the recruitment agents for the Middle East which had sprung up all over India - but particularly in Kerala and Rajasthan - in the 1970s when as the oil boom caused a severe labour shortage in Iraq, Kuwait, United Arab Emirates and Saudi Arabia.
The Boom
This business began to change after N Vittal set up Software Technology Parks in 1990. They were industrial estates; the only difference was that each had a VSAT link which firms located in STPs could use to transmit programmes and data. That by itself did not lead to bigger firms; the early STPs deliberately kept firms small by giving them only 500 square feet of space. But such firms could mediate between domestic software producers and foreign buyers; they could get work done outside the STP and use their link to export it. Thus firms no longer needed to be small.
On the contrary, large firms came to have an advantage. When programmers were being body-shopped, their foreign lessor could put them to any use. But once work came to be done offshore, it had to be in large, self-contained packets. As confidence in Indian firms grew, the packets grew larger.
The clients were always in a hurry; it was advantageous to get a job done quickly by putting a large team on it. The constraint on size imposed by the government on firms in STP disappeared once firms were allowed to set up their own VSAT links. This is how big firms acquired an edge after 1993 - an edge that is reflected in today's TCS, Infosys, Wipro and Satyam.
Small firms did not disappear. In Bangalore and Chennai, a practice of outsourcing work grew up; it allowed firms to take on big jobs without taking more people on their payroll. They could also use cheaper programmers who did not have engineering degrees without employing them directly or revealing to their foreign clients that they used them. The labour shortage also brought forth many training firms; besides NIIT and Aptech which grew big, there were many smaller training firms all over India.
And once Internet became popular in the latter half of 1990s, a great many small firms came up that developed and maintained web sites for clients. Thus, while the coming of VSAT favoured big firms, it did not handicap small firms. There was a lot of work for all to share. Along with these came the domestic demand of IT sevices of the domestic sector fueled by the development of the Intenet and Telecom industry of the new Indian economy. With buzz words like ebusiness and CRM hitting the Indian corporate the industry did phenomenal business.
The Bust and Survival
Then came the meltdown of the IT boom in the US in spring 2000; that transformed the landscape in India. Export orders fell; as demand fell, the big Indian firms stopped outsourcing, and small jobbing firms began to close down. As the market for software cooled, the demand for new programmers fell, and with it, the training firms underwent a slump. And customers soon discovered that Web sites added little to the bottom line; so Web designing business also fell off. Thus, all three mainstays of small firms turned down, and many of them closed shop.
What is remarkable about the Indian software industry is the vast number of firms in it. Nasscom has 800-odd members, IT directories list thousands, and there are many more unlisted anywhere. This is what a recent Nasscom survey showed. There were four groups of firms with substantial exports: big firms with sales over Rs 10 billion commanded roughly a third of the exports, medium firms with sales of Rs 1-10 billion had another third, and branches of foreign firms as well as small Indian firms had each roughly a seventh of the market.
Of these, medium and small Indian firms have lost out to the biggest Indian and foreign firms; the market has favoured size. There were also niche service suppliers and firms concentrating on products, with small market shares of 3-4 per cent; of the two, product firms have done badly.
Then there are firms specialising in IT-enabled services - which has done best of all, better even than the biggest firms. These firms are small; but there is no advantage in smallness here. If this business takes off, there will soon be huge firms employing thousands, as GE is already doing.
Thus, the size structure and specialisations of Indian firms have changed unrecognisably and irrevocably in the past two years. The age of the small, unspecialised, undifferentiated, labour-intensive firm is over. Many think that the business they did will go to China and the Philippines. It will not; it has ceased to exist.
The Future
To grow, Indian firms will have to find something else. What will it be? The IT-enabled services market is huge, and India has a clear advantage in its cheap labour. However, this is precisely the part of industry that is most affected by India's political unreliability. Wars, riots, political extremism - these are just the kind of bad news that can prevent the growth of IT-enabled services. And our politicians will ensure that such bad news will not go away.
That is why the industry needs business that is more stable and less sensitive to bad news. The big firms will try to climb up the value chain - go into business process outsourcing, system integration, and embedded software. They do not need advice; they are scanning the market and will take informed decisions.
But if they are to continue their stellar growth of the past, they will have to find new niches. If they do not, they will die - but more likely, they will leave India and become American firms.
The largest Indian firms are already international. They are quoted in stock exchanges abroad, they have large offices abroad, and they have acquired firms abroad. For them to scale down facilities in India and go away would be easy; and the loss would be entirely India's. If this is to be prevented, India needs better economic management at home.