A sign that social business is growing up

Michael Fauscette made some wise comments about a new company, Pragmatic Enterprise 2.0, that announced itself recently:

without a methodology, a risk mitigation approach, the correct skills and change management a project is doomed. Businesses need enterprise class, scaleable social tools, social processes and knowledgeable assistance to pull off this level of business transformation.

Earlier this week some colleagues announced a partnership that is both good news for businesses that want to do social transformation projects but also an indication that social business is growing up.

I think Michael is right.

I also had a discussion with one of the founders, Michael Krigsman, on Twitter that their product diagram looked like it was designed by a committee and was difficult to understand. I am looking forward to how things develop on that front.

Project Communication

A couple of posts on Paul Rasmussen’s blog prompts me to make my own comments about communication between members of a project team. In The Problem of Communication in Project Management Part 2, Paul discusses the types of communication currently used, which are meetings, phone calls and emails. In Part 3 he mentions new communication technologies – smart phones, wikis and social networking.

Having just been through two projects, I have found that the old ways of communication, particularly face-to-face, are the best for project communication. As we all know, more than 50% of our communication is non-verbal (ie, body language, voice tone), and also as we know, projects success is highly dependent on communication. So as in the case of one project manager, most communication was by email, then mis-understandings can happen. Our company has now instituted a directive that email is not considered adequate communication.

We have tried collaborative tools, such as Basecamp, to help with dispersed team members, but there seems to have been some reluctance to try these new tools. I find that interesting, considering we expect our clients to adopt new tools in the form of ERP solutions. So whether we would benefit from new communication technology is up for debate.

Email can be used to confirm and document facts and issues, however in my opinion, nothing replaces personal contact when it comes to communication.

Why are ERP consultants needed?

In a blog on the ITtoolbox site, Steve Phillips comments that companies are moving away from using external ERP consultants in favour of using in-house expertise – Why ERP Software Consultants Cannot Save The Day.

His view is:

The ownership philosophy is about controlling your project destiny and built on some fundamental principles. … 1) It is possible to take internal responsibility for project management. 2) It is possible to develop and/or acquire internal software expertise to the point outside application consultants are rarely needed. 3) It is possible to become much more educated and less reliant on the false sense of security an army of consultants can bring. 4) It is possible to realize ERP benefits by developing better software and business process solutions with fewer outside consultants. 5) It is possible for internal personnel to do up to 70% of what many pay consultants to do.

Except for item 4, in my experience, I haven’t found any companies that can do what he suggests. I suspect it is a function of certain factors – a primary one being the size of the organisation. But I also believe that business maturity, and the availability of knowledge and experience play a significant part.

In the South African market, most businesses fall into the small-to-medium (SMB) category. Employees in SMB companies tend to take on more than one role (debtors and creditors, pre-sales technical and sales, production planning and management) which leaves them little time to focus on issues which are not directly relevant to the job they must do. So finding time to acquire software expertise is difficult or requires after-hours learning. In time, and if a person stays in the same job, they might become “more educated and less reliant.” However, given their time constraints, it is highly unlikely that people will have the time or knowledge “to do up to 70%” of what a consultant will do.

Also skills and expertise are in short supply in this country, so someone who develop technical skills may easily find themselves moving out of their business job and into a technical or consulting role. Similarly, project management requires experience and time to spend on it, which senior staff in SMBs (e.g., finance managers and directors) rarely have. Companies will tend to have a less senior person overseeing the project, but all the details and work that goes into project management has to be done by someone with the background and time allocation to do it – in other words, a consultant.

In the South African context, therefore, most average companies (not large ones over 1000 people) do not have the people, skills or time to take on an ERP implementation themselves. The cost of bringing in consultants outweighs the risks of failure in trying to do the project in-house.

Truths About IT Costs

A Harvard Business Review article The Truths About IT Costs lists seven ‘truths’ about IT costs. These are:

1. Enhancements often don’t deliver results commensurate with their costs.
2. Projects are often too big and take too long, partly because unnecessary functionality is built into applications.
3. Previously purchased applications and infrastructure technology are often underutilized.
4. Project failure rates are too high.
5. Tech teams do not have sufficient incentive to achieve high quality, and quality is often not measured.
6. Managers don’t know enough about the systems that support their areas.
7. IT is too risk averse: “No one ever got fired for buying IBM or Microsoft.”

The article reads like some consultants’ reports – addressing problems at a high-level, with a few key recommendations; but when you think about it for a while you wonder how to practically implement the recommendations.

Update: see also Michael Krigsman’s critical blog

ETO vs Project Manufacturing

In the ERP manufacturing space, the term ‘order fulfillment‘ refers to the process that manufacturers follow to make goods for customers. The options are:

Make-to-Stock (MTS) The product is built against a sales forecast and put into stock, from where it is sold to customer; e.g., the retail sector.

Make-to-Order (MTO) The product is based on a standard design, but component production and manufacture of the final product is linked to a customer’s order specifications; e.g., high-end motor vehicles.

Assemble-to-Order (ATO) Similar to MTO but the product is comprised of modular components and is built  to customer specifications from a stock of existing components; e.g., the Dell approach.

Engineer-to-Order (ETO) The product is designed and built to customer specifications; this approach is most common for large construction projects and one-off products

Accepted practice with these processes is that a material requirements plan is put together using the Bill Of Material (BOM – the components, production operations, inventory and lead times) of the product, following which a master production schedule (MPS) is developed from the order, inventory and production information available.

The company I work has, for a number of years, been growing its experience and expertise in the custom-production areas of the order fulfillment process; what some would call ETO. We have been finding that although ETO-type manufacturers never build the same product twice, and may have many unique orders being built simultaneously, they consider it sacrilege to go against the concept of a BOM; even though a BOM is only really applicable and useful if you can re-use it.

I have encountered manufacturers who think that they have to a BOM to make their products. But when you probe deeper you discover that what they make is unique (ie, project-driven) and therefore requires a new BOM everytime.

A few companies, however, are starting to follow a new practice – what we have called for the moment, Project Manufacturing (PM).

As Frank Scavo pointed out in his blog:

“For organizations that are project-based … there is a great need to integrate project management with ERP … the project schedule is (or should be) the master production schedule. Requirements for material, labor, outside services, and other resources are directly tied to the work breakdown structure. ERP systems based on a traditional MRP approach simply do not work. Project-based organizations are relatively under-served by enterprise system vendors.”

These project-oriented manufacturers follow the PM approach – using project management software applications to do their detailed manufacturing planning, rather than an MPS. The labour and material allocations that conventionally are done via the BOM are managed via the work breakdown structure (WBS) of the project plan. Frank’s comment that these types of manufacturers are ‘under-served’ is an under-statement. None of the standard and well-known ERP vendors provide this type of functionality.

We have had the privilege of working with a few leaders in the PM space in South Africa, and help them to develop the integration of project management and ERP. It can be quite a culture shock for someone coming from a standard manufacturing process to adapt to the PM approach, and in my case it took over a year to develop a deeper understanding of the processes and technology involved.

The purpose of this blog article is to introduce the concept of PM, and find perhaps a better acronym. In later blogs I will go into more detail about how PM differs from the other order fulfillment options, how to allocate labour and materials in the WBS and then link it to the ERP system, how it works from a software and process perspective, and what it involves for project implementation. In the meantime, comments would be most welcome.

Does high project failure require "professionalising" IT?

Two recent blogs by Michael Krigsman discusses how high IT project failure rates are, and some of the key reasons.

Study: 68 percent of IT projects fail
Requirements and failure: Interview with CA’s SVP of IT Governance

I am friends with a number of professional engineers – civil, mechanical and electrical – and I don’t believe they would dare to operate if the failure rates of their projects was anywhere near as high.

Michael identifies issues relating to lack of skills, knowledge and competency as the key factors leading to failure. Skills, knowledge and competency are what training and education programs are supposed to develop. People go to university to acquire skills and knowledge. But for professionals like doctors (my wife being one) and engineers, a university degree only starts the process. The engineering companies I know expect to train young engineers for several years before they are ready to be let loose.

But when it comes to IT, customers often think they have the in-house capacity to for projects. I think many people also look at software like Microsoft Office and think that implementing and using software is easy.

Many years ago in South Africa, there was a debate in the Computer Society about whether IT should become a profession. At the time, the proposal was defeated. After reading Michael’s blog, I am wondering whether we should re-look at the proposal. The next step would  be where do you start, and would IT vendors, consultants and users see this as beneficial?

In engineering, aircraft engineers must be a relatively recent addition as a profession. So how did they go from being a bunch of techies to having their own professional status?

BTW, I suspect that the information Michael uses comes from projects in the more well-resourced developed economies, so I wonder how the projects perform for those of us in developing countries?