Online project repository

I started my business career in an organization that, on brochure, stated to have 70000 employees worldwide, and, pre-Internet and widespread use of PCs (secretaries used first typing machines, then Wang workstations), had over 5000 employees in a central office structuring collecting information from each project worldwide This map represents the taxonomy that I used in producing my own online project repository that will be online at robertolofaro.wordpress.com from 2010-09-27, i.e. an abstract and knowledge sharing tool using my experience to show how knowledge obtained in activities can be classified and accessed. Beside the repository, I actually used most of these categories both to produce new proposals based on my experience since 1993 (and for limited activities and my employers since 1988), and to "classify" potential partners according to their potential contribution on each activity. And, last but not least, this taxonomy represents the typical questions that, since my time in Andersen on DSS/EIS (sometimes a project a day), I asked to the partner or manager before visiting the customer site, so that I could review if I had the information needed to get past the first 5 minutes with the customer (the "judgement time") and proceed on the real business It is based on over few hundreds of projects and accounts I worked on with different roles from 1986, in various European countries and industry, with project size ranging from tiny to huge. Five dimensions of analysis: - By industry and customer structure - By project category, organization, team size. See on the description of each dimension of analysis for more information Why not by role or paid/unpaid? Because those are elements irrelevant to the qualification of the project and the experience acquired on each project. Once started, paid or unpaid, as information janitor or as supreme leader, a project or activity evolves- and any member of the team should contribute. So, the pricing and content negotiation has to be done before the project: I always found puzzling those starting activities and (both customers and team members) changing the pricing structure. Not my call to judge- but not my style to adopt such an approach. Anyway, that's why I prefer to convert any activity, include time&material, into a "fixed price", with deliverables and time associated with the price agreed- and any flexibility of the latter two elements always to be balanced vs the original agreement: I was part of way too many projects were the "leader" let the scope spin out of control, assuming that the customer would sign off any price increase- but never checking.

Category
"Category" is more appropriate for projects than for activities (e.g. service management), but it covers both In some cases, a project becomes a service, while in others a service generate ad hoc projects (e.g. to review existing service processes) The difference (often forgotten)? A project must begin and end- if a project keep expanding its scope, I prefer to "spawn" and negotiate new projects, and adding a programme structure, or convert the original project into a programme (albeit I strongly suggest to keep a project a project, and create a new programme structure, if needed). And if a project is a recurring activity- separate the service component (what is always there) from the ad hoc recurring activities, as probably the staffing and skills required for the recurring activity will be fairly different from the ones required to staff the day-by-day operations. Make you a favour, and read four books Three from OCG (on PRINCE2- projects, ITIL- services, MSP- programmes: it is enough for a panoramic view to read the free introductory documents available online), and one from the UN publishing side, a book by Milan Kubr on Management Consulting (old but still useful to understand the issues in delivering consulting activities) As for the specific members of "Category": those are the ones I used in my activities, and are not mutually exclusive; e.g. often a data warehousing or DSS activity included reviewing the processes or purpose of each unit, a management consulting activity, facilitating meetings to obtain the desired perspective, and coach people on following the new rules- plus a mix of the other activities
1. Business and Data Analysis (incl. DSS, EIS, DWH, BI)
2. Coaching, Training, Facilitating
3. Management Consulting
4. Marketing, Business Development, Negotiation
5. Service Management and Outsourcing
6. Other technological
Customer structure
Based on my business experience with various organizations (I had worked on or had contacts and had to review/profile at least few hundreds, since the 1980s), this category replaces the most common "Private vs. public" dichotomy
1. Corporations, Governments, Institutions
2. Non-profit
3. Startups and SMEs
Industry
The "industry" can be considered a little bit quixotical- but it is organized around the results of my business experience- more on flows and the "forma mentis" of processes than on details It will make more sense after all the projects and activities I worked on will be published online If you prefer, adopt another classification; suggestion: keep it to a limited number, and avoid "others"
1. Automotive, Logistics, Transportation
2. Banking, Finance, Insurance
3. Consulting, Professional Services, Software
4. Electronics and FMCG
5. Infrastructure and Building
6. Governments and Institutions
7. Pharma and Biosciences
8. Retail and Clothing
9. Energy, Telecommunications, Media
Organization
As the size, the communication and team dynamics depends on the activity/project organization: but while the team size can fluctuate due to external reasons (e.g. the supplier has people idle in the office, so they will try to dump them on projects, also if this means having three people doing the work of one), the parameters in this category are not mutually exclusive you can have a project that is multi-vendor, with part-time staff, on multiple sites, and with people from different cultural backgrounds (both in terms of language/ethnicity and experience- e.g business vs technical) your communication processes and structure, notably the informal ones, depend on this combination of factors as much as they depend on the customers' rules and processes and, sometimes, to produce a cooperative spirit, a multi-vendor team has to build a "bubble", adopting informal communication channels that, while not formally sanctioned by each one of the contributing companies, is needed to produce the results that all the parties involved want to achieve it is typical: in a multi-vendor environment, there will always be some "territorial scope creep" attempt done by a naive local manager or initiated by a visiting supervisor while it is understandable, in my experience eventually creating a more cooperative environment (not friendly, cooperative) is grudgingly acknowledged to be more productive and allows to cope with the usual unknowns- i.e. changings in regulations, issues with the resources available, need to complement the skills or reschedule activities
1. Multi-vendor
2. Part-time
3. Multi-site
4. Multi-cultural
Team size (peak)
The team size is something that is often ignored, but the peak size of the team should be considered as part of the organization of every activity. If you structure communication processes for the wrong size, you risk introducing excessive overhead (e.g. forcing everyone to write as if each document had to be used by more than one person). Or, on the opposite end of the spectrum, create something that is fine when two people are working side-by-side day after day, but is based on person-to-person communication: not really the best way if you have suddenly the 5 people that you asked for and never received the team size dynamics in the typical project is that you get all the people you don't want when they have nothing to do, while you have to haggle to keep the people you need when everything is going fine, but the big time is just around the corner and this bring the point of the "peak" in the category size: in my projects and activities, given the choice, I do not want more people than needed (actually, I find easier to manage with a little bit of shortage)- to avoid people "kicking tires" by wasting the time of those working, or to have to invent work to keep them busy (idle minds can wreak havoc) the team size should vary across time- and some people could be needed in some phases with an operational role (doing something) and as a "one-person competence center" later on, to return again to an operational role when it is time to close the activity a caveat: my approach on team sizing is also due to the small issue that, for various reasons, I almost never worked full-time on a project, and I was often split across multiple activities: hence, the need to avoid that "idle minds" keep themselves busy by inventing something that damages the relationships between the team and the stakeholders
1. 1-5
2. 6-10
3. over 10