5th Edition PMBOK® Guide—Chapter 5: Process 5.2 Collect Requirements


According to the PMBOK® Guide, this process determines, documents and manages stakeholder needs and requirements in order to meet the project objectives.

The inputs are the management plans that give information about the requirements, and the stakeholders that will need to be consulted in order to carry out this process.

The tools & techniques contain a variety of different methods for developing the requirements.

The outputs are the requirements documentation and requirements traceability matrix.

5.2 COLLECT REQUIREMENTS
INPUTS
1. Scope Management Plan How project teams will determine which type of requirements need to be collected for the project.
2. Requirements Management Plan Provides processes that will be used throughout to define and document the stakeholder needs.
3. Stakeholder Management Plan Used to understand stakeholder communication requirements and the level of stakeholder engagement in order to assess and adapt to the level of stakeholder participation in requirements activities.
4. Project Charter High-level description of the product, service, or result of the project so that detailed requirements can be developed.
5. Stakeholder register Identifies stakeholders who can information on the requirements, and captures major requirements and main expectations stakeholders have for the project.
TOOLS & TECHNIQUES
1. Interviews Aids in identifying and defining the features and functions of the desired product deliverables.
2. Focus groups Used to learn about expectations and attitudes about a new product, service, or result.
3. Facilitated workshops Focused sessions that bring together key stakeholders to define product requirements.
4. Group creativity techniques Organized to identify product and project requirements.
5. Group decision-making techniques An assessment process having multiple alternatives with an expected outcome in the form of future actions. These techniques can be used to generate, classify, and prioritize product requirements.
6. Questionnaires and surveys Written sets of questions designed to quickly accumulate information from a large number of respondents.
7. Observations It is helpful for detailed processes when the people that use the product have difficulty or are reluctant to articulate their requirements.
8. Prototypes Obtains early feedback on requirements by providing a working model of the final product.
9. Benchmarking Compares actual practices, such as processes and operations, to those of comparable organizations in order to generate best practices.
10. Context diagrams A scope model which visually depicts the product scope by showing a business system and how people and other systems interact with it.
11. Document analysis Elicits requirements by analyzing existing documentation and identifying information relevant to the requirements.
OUTPUTS
1. Requirements documentation Consists of the following categories of requirements:

  • Business requirements
  • Stakeholder requirements
  • Solution requirements
  • Project requirements
  • Transition requirements
  • Requirements assumptions, dependencies, and constraints.
2. Requirements traceability matrix Traces requirements with respect to the following:

  • Business needs
  • Project objectives
  • Project scope/WBS deliverables
  • Product design
  • Product development
  • Test strategy and test scenarios
  • High-level requirements to more detailed requirements

The important thing is that the needs and requirements of the customer and other key stakeholders need to be translated from high-level requirements to more detailed requirements that eventually will turn into the deliverables that comprise the Work Breakdown Structure.

The next post will give an overview of the next process, 5.3 Define Scope.

5th Edition PMBOK® Guide: Chapter 5—Requirements Management Plan


The process 5.1 Plan Scope Management has the purpose of creating a framework for most of the other scope management processes. Four of these processes (5.3 through 5.6) are reflected in the Scope Management Plan, and one of them 5.2 Collect Requirements is reflected in another project management plan, the Requirements Management Plan.

The purpose of this post is to outline the elements of the Requirements Management Plan as laid out by the PMBOK® Guide.

Element of Requirements Management Plan Explanation
1. Requirements activities management Manages how these activities will be planned, tracked, and reported 
2. Configuration management activities
  • How changes to the product will be initiated
  • How they will be traced, tracked, and reported
  • Authorization levels required to approve changes
3. Requirements prioritization process If two or more requirements are in conflict, which receive priority? 
4. Products metrics Which metrics will be used and why? 
5. Traceability structure Which requirement attributes will be captured on the traceability matrix?

So the two project management plans, the Scope Management Plan and the Requirements Management Plan, are the outputs of the process 5.1 Plan Scope Management.

The next post will describe the next scope management process, 5.2 Collect Requirements.

5th Edition PMBOK® Guide—Chapter 5: Scope Management Plan


1.  Introduction

The output of process 5.1 Plan Scope Management is, not surprisingly, the Scope Management Plan. You should be aware that in previous editions of the PMBOK® Guide, this process did not exist. What, you may say, they didn’t use to create a Scope Management Plan? Well, no, not exactly. A Scope Management Plan was created, but it was done as part of creating the most general Project Management Plan as part of 4.2 Develop Project Management Plan. But to emphasize that each knowledge area does require the creation of its own management plan, the 5th Edition of the PMBOK® explicitly creates a separate process doing just that.

The purpose of this post is to look at the elements of what is in a Scope Management Plan.

2.  Elements of the Scope Management Plan

As mentioned in an earlier post, the main purpose of the scope management plan is to provide the framework for most of the other 5 scope management processes. You can see this if you look at the following table of the elements of the plan.

Element of Scope Management Plan Related Scope Management Process
1. Process for preparing detailed project scope statement 5.3 Define Scope
2. Process that creates WBS from the detailed scope statement 5.4 Create WBS
3. Process that establishes how the WBS will be maintained and approved 5.4 Create WBS
4. Process that specifies how formal acceptance of the completed project deliverables will be obtained 5.5 Validate Scope
5. Process to control how requests for changes to the detailed project scope statement will be processed 5.6 Control Scope

The only scope management process not mentioned, 5.2 Collect Requirements, is covered by another management plan, the Requirements Management Plan, and this the other output of process 5.1 Plan Scope Management, and is covered in the next post.

5th Edition PMBOK® Guide—Chapter 5: Project Charter vs. Project Scope Statement


1. Introduction

In this particular post, I review the differences between the Project Charter and the Project Scope Statement. There are differences between them, but both of them have some common elements, so it may be difficult to distinguish them. The purpose of this post is to make the distinction between them clearer.

2. Project Charter vs. Project Scope Statement: Processes

The project charter is something that is an output of the process 4.1 Develop Project Charter. This is in the Initiating Process Group. As such, it is a document that is created at a high-level (broad-based rather than detailed) for the purpose of getting the project approved by the sponsor.

Once the sponsor says “yes” to the project, then the project manager can proceed to the Planning Process Group and create the Project Scope Statement as an output of the process 5.3 Define Scope. The Project Scope Statement is created at a detailed level from the general description of the Scope contained in the Project Charter, (an output of process 4.1 Develop Project Charter), along with the Scope Management Plan (an output of process 5.1 Plan Scope Management), and the Requirements Documentation (an output of process 5.2 Collect Requirements).

3. Project Charter vs. Project Scope Statement: Contents

Here are the elements of the Project Charter (used for approval of the project) compared to the elements of the Project Scope Statement (used in planning of the project). Those elements which are similar are put in the same row.

Project Charter Project Scope Statement
a. Project purpose or justification (fits business needs, strategic plan)
b. Project objectives, product characteristics a. Project scope description
c. High-level requirements b. Deliverables
d. Project assumptions, constraints, high-level descriptions, boundaries c. Project exclusion, constraints, assumptions
e. Project success criteria d. Project acceptance criteria
f. High-level risks
g. Summary schedule, budget
h. Stakeholder list
i. Project approval requirements and approval authority
j. Project manager assigned to project

As you can see, the project charter contains elements that deal with the justification for the project, who is running the project, and who has authority and approval over the project. But in addition, there are elements from the following knowledge areas:

  • Scope management
  • Cost management
  • Time management
  • Risk management
  • Stakeholder management

As you can see from the Project Scope Statement fleshes out in detail those portions of the Project Charter that specifically deal with the Scope Management Area.

5th Edition PMBOK® Guide—Project Statement of Work vs. Project Charter


1. Introduction

The Project Statement of Work is an input to the 4.1 Develop Project Charter process in the Initiating Process Group. The output of that process is the Project Charter.

The purpose of this post is to make the distinction between the Project Statement of Work and the Project Charter clearer. I will do this by answering the questions: What is it? How does it fit in the flow of PM processes? Who creates it? What’s in it? How does it compare to the Project Charter? How is it related to procurements?

2. Project Statement of Work (SOW)—What is it?

The best way I can describe the Project Statement of Work is as the “seed” of the project. It is watered during the Initiating Process into the Project Charter which causes it to germinate and become a seedling. The seedling is planted in the ground during the Planning process of creating the Project Scope Statement. It then turns into a plant during the Executing Process (where it is given sunlight and water, analogous to project resources) and Monitoring & Controlling Process (where it is checked periodically to see if there are any adverse conditions such as pests or diseases), and is finally harvested at the time of the Closing Process.

3. Project Statement of Work (SOW)—How does it fit into the flow of PM Processes?

The SOW is the seed or kernel of the idea for the project which is then developed at a high level for the purpose of approval of the project during the Initiating Process Group as process 4.1, Develop Project Charter. As seen in the previous post, this Project Charter, if approved, is developed at a higher level of detail in the Planning Process Group as process 5.3, Define Scope. So here’s the flow of how the documents are connected:

3. Project Statement of Work (SOW)—Who creates it?

This is going to depend on the end result of the project is going to be a product, service, or result that is used internally within the company, or is to be delivered to an external customer.

If the sponsoring organization is the one that is going to use the end result, then the sponsor is the one that originates the SOW. If a customer is the one that is going to use the end result, then the customer is the one that originates the SOW. The SOW may be part of a bid document (request for proposal, request for information, request for bid) or as part of a contract.

4. Project Statement of Work (SOW)—What’s in it?

The PMBOK® Guide references 5 inputs to the 4.1 Develop Project Charter process, two of which are the generic Enterprise Environmental Factors (EEF) and the Organizational Process Assets (OPA), the “company culture” and “company processes” that are inputs to many PM processes. The other three are the Project Statement of Work, the Business Case, and Agreements.

However, listing these three like this is somewhat misleading and obscures their interrelationships. Here are more detailed descriptions of these three inputs

a. SOW
The components of the Project SOW are as follows:

Element Description
1. Business need Why do the project? Because of some external factor such as:

  • Market demand (new demands create new products)
  • Technological advance (taking advantage of new materials and/or available technologies
  • Legal requirement
  • Government regulations (environmental, safety, etc.)
  • Environmental consideration
2. Product scope description Characteristics of the product, service, or result for which the project is undertaken. What is the relationship between that product, service, or result and business need the project addresses?
3. Strategic plan The project must contribute to the organization’s overall objectives or high-level mission statement.

b. Business Case

How is the business need different from the business case? The business case takes the business need outlined in the SOW (element 1 in the chart above) and justifies how the result of the project (element 2 in the chart above) will satisfy that need AND align with the strategic goals of the organization (element 3 in the chart above). It is the analysis that ties together the 3 elements of the SOW like so:

c. Agreements

As mentioned above, IF the product is to be made for a customer, then the SOW may come from the contract, a memorandum of understanding (MOU), a letter of intent, or some other form. The key is that the statement of work may come either internally (from the sponsor) or externally (from the customer).

I hope this explanation clears up the distinction between these three inputs of the process 4.1 Develop Project Charter other than the generic EEFs and OPAs.

5. Project Statement of Work: How does it Compare to the Project Charter?

Here are the elements of the Project Statement of Work (the “seed” idea of the project) compared to the elements of the Project Charter (used for approval of the project). Those elements which are similar are put in the same row. In this chart, the elements 1 and 3 from the above chart on the Project Statement of Work correspond to the first element of the Project Charter, and element 2 from the above chart corresponds to the second element of the Project Charter.

Project Statement of Work Project Charter
a. Business need, strategic plan a. Project purpose or justification (fits business needs, strategic plan)
b. Product scope description b. Project objectives, product characteristics
c. High-level requirements
d. Project assumptions, constraints, high-level descriptions, boundaries
e. Project success criteria
f. High-level risks
g. Summary schedule, budget
h. Stakeholder list
i. Project approval requirements and approval authority
j. Project manager assigned to project

The Project Statement of Work is therefore the core of the first two elements of the Project Charter.

The other elements of the project charter deal with the project scope rather than the product scope (Project assumptions, constraints, high-level descriptions, boundaries), the criteria for success and those risks that may prevent the project from being successful, the high-level constraints of time and cost, the stakeholder list, the project approval requirements and authority, and finally, the actual project manager assigned to the project.

The next post will discuss the difference between the Project Charter, the output of 4.1 Develop Project Charter and the Project Scope Statement, the output of 5.3 Define Scope.

5th Edition PMBOK® Guide–Chapter 5: Process 5.1 Plan Scope Management


The first process in the Scope Management knowledge area, process 5.1 Plan Scope Management, has the object of creating the Scope Management Plan, which is the framework for all the other five processes from the Scope Management knowledge area.

The main input is the project charter, and by using the tools and techniques of consulting with knowledgeable individuals (expert judgment) and in groups (meetings), the two main outputs are the Scope Management Plan itself and the Requirements Management Plan.

Below is a table summarizing these inputs, tools & techniques, and outputs.

5.1 PLAN SCOPE MANAGEMENT
INPUTS
1. Project Management Plan (The PMBOK Guide mentions that some of the subsidiary plans of the Project Management Plan are used as inputs to create the Scope Management Plan, but unfortunately fails to mention which plans are used.)
2. Project Charter The high-level project description and product definition.
3. EEFs In particular, the

  • Organization’s culture
  • Infrastructure
  • Personnel administration
  • Marketplace conditions
4. OPAs There are two categories of OPAs, the first being policies and procedures, and the second being historical information and the lessons learned database.
TOOLS & TECHNIQUES
1. Expert judgment Any person with expertise in creating a Scope Management Plan.
2. Meetings Meetings to develop the Scope Management Plan involve stakeholders who are responsible for scope management.
OUTPUTS
1. Scope Management Plan Describes how the scope will be defined, developed, monitored, controlled, and verified (i.e., the contents of the other five scope management processes).
2. Requirements Management Plan Describes how requirements will be analyzed, documented and managed.

Before we go on to the next post, I will go into detail regarding three topics: a) the difference between the Project Statement of Work (SOW) and the Project Charter, b) the contents of the Scope Management Plan, and c) the contents of the Requirements Management Plan.

5th Edition PMBOK® Guide—Chapter 5: Scope Management Knowledge Area Processes


In the last post, I gave a general introduction to Chapter 5 of the PMBOK® Guide, the Scope Management knowledge area.

This post contains is a summary of the six project management processes that are in the Scope Management knowledge area.

1. Scope Management Knowledge Area—Six Processes

You will notice that the Scope Management Knowledge area, as well as the following two knowledge areas of Time and Cost, only have processes in either the Planning Process Group or the Monitoring & Controlling Process Group. In particular, the Scope Management Knowledge Area has four processes in the Planning Process Group, and two processes in the Monitoring & Controlling Process Group.

Process

Group

Process Number Process
Name
Process Description
Planning
5.1 Plan Scope Management The process of creating a scope management plan that documents how a project scope will be defined, validated and controlled.
5.2 Collect Requirements The process of determining, documenting, and managing stakeholder needs and requirements to meet project objectives.
5.3 Define Scope The process of developing a detailed description of the project and product.
5.4 Create WBS The product of subdividing project deliverables and project work into smaller, more manageable components.
Monitoring & Controlling 5.5 Validate Scope The process for formalizing acceptance of the completed project deliverables.
5.6 Control Scope The process of monitoring the status of the project and product scope and managing changes to the scope baseline.

Let’s take a closer look at the process descriptions.

5.1 Plan Scope Management

This is a new process in the 5th Edition of the PMBOK® Guide. This is not to say that the scope management plan was never done before, it’s just that the process of creating that plan was considered part of the larger generic process 4.2 Develop Project Management Plan. Now, however, EACH of the knowledge areas has its own process that is dedicated to planning.

In the case of the Scope Management Plan, the plan gives details on how the project scope will be defined (processes 5.2 through 5.4), validated (process 5.5) and controlled (process 5.6). It therefore charts how the organization will chart its way through the rest of the scope-related processes.

5.2 Collect Requirements

This takes the high-level needs and expectations of the sponsor, customer, and other stakeholders outlined in the project charter and translates them into detailed set of requirements that can be analyzed for possible inclusion in the scope baseline.

5.3 Define Scope

This is the detailed description of the project and product, which includes which of the requirements collected in the previous process will be included in the scope and which will be excluded. The output of this process is the Project Scope Statement, one of the three components of the scope baseline.

5.4 Create WBS

This is the process of subdividing the project deliverables and project work into smaller, more manageable components called work packages. The output of this process is the work breakdown structure or WBS, and the WBS dictionary, which contains detailed information about the contents of the work packages. The WBS and WBS dictionary are the other two components of the scope baseline besides the Project Scope Statement.

5.5 Validate Scope

The interim deliverables are formally accepted by the customer or sponsor as a way of making sure that everybody is on the “same page” when it comes to the project progressing along the lines of the performance baseline, which in the case of the scope management knowledge area means the scope baseline in particular.

The deliverables are internally verified to make sure they meet the requirements (as part of the Control Quality process), and then the Validate Scope process makes sure they are either externally validated by the customer or, in the case of a purely internal project, with the sponsor of the project.

5.6. Control Scope

Control Scope is the process in the Monitoring and Controlling Process group which attempts to maintain the project within the scope baseline if possible. If it is not possible and the scope must be changed, then the process may generate as an output a change request which may (if approved) lead to a changed scope baseline.

This is a basic outline of these processes. Tomorrow I will go through the inputs, tools & techniques, and outputs of the first process, 5.1 Plan Scope Management.

5th Edition PMBOK® Guide—Chapter 5: Product vs. Project Scope, Scope Baseline


I am now starting a series of posts on the 5th chapter of the PMBOK® Guide, which covers the first of the individual knowledge areas besides Integration which can be seen as tying all of the other knowledge areas together.

Scope Management is the first individual knowledge area perhaps because its management is perhaps the most crucial to the success of a project. Scope creep, or the inability to manage the scope, is one of the most common reasons for a project to get out of hand and not meet the other constraints of being completed on time and within the budget.

1.  Product vs. Project Scope

To start the discussion of this chapter, let me begin with a discussion of the distinction between the scope of the product and the scope of the project.

Scope

Definition

Scope Contained in…

Product Features and functions that characterize a product, service, or result Product requirements
Project The work performed to deliver a product, service, or result with the specified features and functions. Project management plan

2.  The Scope Baseline

The scope baseline, against which the performance of the project is measured, consists of three elements.

  1. Project scope statement
  2. Work Breakdown Structure
  3. WBS Dictionary

The processes that create the scope baseline are found in the planning process group. The processes that can potentially change the scope baseline are found in the monitoring and controlling process group. The next post will outline these two sets of processes.

#FSI Language Courses have Disappeared! UPDATED


1. FSI Language Courses

I wrote a review last year of the fsi-language-courses.org website, saying that it was a great free resource for those learning foreign languages. It contained courses developed by the Foreign Service Institute in the 1980s and earlier for members of the government who needed to be able to speak foreign languages fluently as part of their position.

Although my understanding was that these courses were in the public domain, I had it in the back of my mind that it wasn’t the Foreign Service Institute itself who was maintaining the website, but some linguistic do-gooder who had taken it upon himself to make the courses available for the general public.

Personally, I have used the courses for Advanced Spanish, French, and German, and was currently going through the materials on the Standard Chinese: A Modular Approach course. Or I should say reviewing them, because I happened to take a Chinese course at the University of Illinois in the 1980s which utilized the materials.

Last year I had taken the Chinese proficiency exam HSK (Hanyu Shuiping Kaoshi) at the third level out of six. The Chinese have in the past few years realigned their language proficiency exam levels to correspond to the European Common Reference Framework for language levels.

2. European Common Reference Framework for language levels

Here is an explanation of the European Common Reference Framework


 

Level

Explanation

A1

Beginner

Can introduce oneself and understand familiar everyday expressions.

A2

Elementary

Can describe oneself and communicate about one’s immediate environment.

B1

Intermediate

Can talk about past and future events and about most situations encountered at work or school.

B2

Upper Intermediate

Can communicate about simple ideas and concepts in a way that is generally understood.

C1

Advanced

Can communicate about complex ideas and concepts in a way that is easily understood.

C2

Fluent

Can summarize complex idea and concepts and create coherent presentations.

Some language proficiency tests cover all four areas of reading, writing, speaking and listening, such as the French DELF (Diplôme élémentaire de langue française) or the Spanish equivalent DELE.

Some tests cover reading, writing, and listening, but do not have a speaking component, such as the Chinese HSK or the Japanese Language Proficiency Test.

I found the FSI Language materials good in terms of reviewing grammar and doing drills to help you remember vocabulary. Some courses take you all the way from beginning level A1 through B1, and other Advanced Courses go from B2 through C1 in terms of the level of language you are using.

The best course in my opinion was the Chinese course because besides having a well-developed textbook and audio materials, there were an extensive series of practical exercises helping you use the language in situations that were as close to real life as possible. Each module would be grouped around a series of practical linguistic skills, such as

  • Module 1: Orientation, where you learn to be able to introduce yourself
  • Module 2: Biographical Information, where you learn to tell about your immediate family and extended family background
  • Module 3: Money, where you learn to be able to count the currency of either Taiwan or Mainland China, be able to exchange traveler’s checks and purchase items in a store
  • Module 4: Directions, where you learn to be able to tell a taxi driver where the address is you want to go

These aren’t the only skills learned in the modules, but they give an example of how they were geared towards practicality as opposed to an academic course that would train you to read and write the language for academic purposes.

3. Where are the materials now?

I had downloaded module 3 in January, after not being able to so for a couple of weeks for what I assumed was server maintenance (a lot of places use the holidays for that sort of thing these days). When the site was up, I presciently decided to download module 4 just in case.

When I went to double check the site this weekend to make sure I had downloaded everything, I got the following message

“FORBIDDEN: You don’t have permission to access / on this server. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.”

I checked at the following website and quite a few people have also been remarking recently that the FSI Language Courses site is down:

http://ielanguages.com/blog/death-of-a-language-website-fsi-language-courses-org/

Some temporary solutions being offered by the commenters (more of whom are commenting every day on this site, it seems) are:

  • Having volunteers upload the materials they already have to a site so that others may at least share what people have
  • Going to an archive of the FSI Languages Courses webpage
  • Wait and see what happens to the website

The first option is fine if you just happen to want a course that somebody else has uploaded, but you’re out of luck if it is not there.

The second option is no good–the archive page contained the layout of the old webpage, but none of the links are functional, at least for the Chinese language course which is the one I tested.

The third option is what I am going to do for now because either the site is down again for maintenance, in which case it will be up in a week or so like it was last time around the Christmas holidays. Or it will be down permanently, in which option 1 is the only viable option, I’m afraid. For now, if you have ever used FSI Language Course materials or are interested in using them in the future, monitor the website and the link up above which seemed to be popular internet gathering around this topic.

If the situation changes, I will update this post and send a tweet about it with my Twitter account which also uses the handle 4squareviews. At least I know that if the site does go away, that there are enough language-learning fans out there that it will be sorely missed!

UPDATE:   FSI Language Courses are now available at the site fsi.antibozo.net!   Thanks so much, Jennifer, for letting me know about this alternative site!

The Great #African Renaissance—an EIU Webinar


This post is a summary of a conversation that Jane Morley, a Senior Editor at the Economist Intelligence Unit had with Paul Lewis of Economist Education on February 28th, 2013.

1. Introduction

The continent of Africa is growing faster than any other place in the world other than India and China. The fastest growing economies in the continent are Angola, Nigeria, and South Africa. Most of the other countries are expected to grow quickly as well; there are some exceptions such as Zimbabwe and Swaziland, but these are in the minority.

2. What is driving growth in Africa

a. External demand from China and India, particularly for natural resources such as oil (Nigeria and Angola) and minerals (Tanzania). This demand is keeping commodity prices high, which has fueled much of Africa’s growth recently. Oil has been discovered in Uganda recently and in Kenya as well.

b. Domestic demand driven by increasing urbanization and rising disposable incomes. This is true of emerging service sectors such as telecommunications and banking, but in traditional sectors such as agriculture (Ethiopia, Rwanda).

c. Political changes have brought stability and growth. Improved economic management after the debt relief in 2006 and 2007 has led to increased capital inflow.

d. Demographics: Africa has the youngest and most populated market in the world. More than half of population is under 24. By 2050, Africa’s population will be 2 billion, greater than the 1.6 billion in India or 1.4 billion in China. Urbanization is rapid: 40% of Africans live in cities; lower than China but higher than India, but by 2030, urbanization will increase to 63% of Africa. Meanwhile, the middle class is growing and families are starting to have fewer children. 10 years ago the average African woman had 6 children; today she has 5 (compared to the average of 1.7 in Asia). The growing middle class will create demand for schools and utilities.

3. Country profiles—a sampling of differing outcomes in Africa

Here are sample profiles of some of the countries in Africa, with the opportunities and challenges faced by them.

Country Opportunities Challenges
Nigeria Demand for alternative energy is growing

 

Violence may deter investors
South Africa Growth should rise from 2.5 to 4% in the next 3 years;inflation will reduce from 6 to 5%

 

Growth far below potential
Kenya Last year’s moderation of inflation should benefit this year’s growth Election-related violence may curtail tourism and investment

 

Ghana Growth is robust, broad-based; emerging middle class driving consumption growth

 

Nascent oil and gas sector presents huge challenge
Zimbabwe Conduct and outcome of elections will be crucial Power-sharing administration would be worst outcome because most of the energy of government would be spent on infighting

4. General Challenges

Some of the general challenges faced in Africa are that some government backing and regulatory support, in addition to the financial investment, are necessary in order to have investments thrive.

However, rapid policy improvement in order to reduce bureaucracy is taking place in Africa, and this should accelerate growth in the future. Free trade zones are a popular policy idea but they do not yet function well. It is even more difficult to unify fiscal policy between countries, so this is a development that will take a long time in order to bear fruit. But the potential rewards are enormous, and this promise should help propel things forward.