Project Management

To hit pay dirt

by
Hi to all of you, and welcome to this blog about management, projects, IT, etc. and about life among all of that. I'd like to share my thoughts, knowledges, experiences and to propose them for discussions.

About this Blog

RSS

Recent Posts

Business processes and project management processes: correlation, integration, evolvement

Interesting research. Who will be next? Would it be possible?

What does a business need first in order to begin growing?

Inspiration interaction

New Year...new digital workplace trends...AI and robots

What does a business need first in order to begin growing?

Any business development starts with process organization. Before starting a new business or expanding an existing business, we need to have clearly defined processes and a clear understanding of these processes. If we don’t, we will only increase the chaos. We even risk destroying any good assets which we have, including our relationships with customers. If we are just starting our business, we are also going to need a clear understanding of which processes we will need.

It does not matter how many people there are. If there are a lot of people and departments, then processes will be distributed among the departments and people. If there are not enough people, each person will need to perform more functions, and we will know what people we need based on the number and types of functions. In a startup, often one person wears many hats.

So what would we do first?

According to the guide ISO 9001, businesses are divided into the following process groups:

  • management processes;
  • main processes;
  • supporting processes.

 

The processes in the first group and the third group are almost the same for different businesses. 

The Management processes are the activity of creating the strategy and forming the development direction, management model and principles. 

This first group includes the following processes:

1)   Strategic Management;

2)   Quality Management;

3)    Organization Management;

4)    Contractor Management;

5)    Customer Management;

6)    Partner Management;

7)    Public Relations Management;

8)    Financial Planning and Budgeting.

The main processes are the activities directly assumed by the charter company documents and forming the main product for the market/society.

How would we know these main processes? 

The main processes depend on what kind of business you have.

At the beginning we need the clear understanding your goal. After that we have to formulate the main tasks which you will want decide to reach your goal.  

So, we know our main processes.

Auxiliary/supporting processes are activities, which are necessary to support the main processes, to form a single platform and typical rules of the unit and processes interaction within all other processes.

This third group includes the following processes:

1)  Regulatory Information Management;

2)  Project Management;

3)  Information Technology and Security Management;

4)  Workflow Document Management;

5)  Archive Documents storage;

6)  Stuff Management;

7)   Transportation Management;

8) Administrative Management

9)   Supply Chain Management.

When we know our processes we have to describe their inputs and outputs. Process inputs and outputs can be material, financial and information. Each business has own inputs and outputs.

If we only create a company, we describe our company model. If we already have a company, we also describe the model, in this case we don't need to think about our current structure when you make description, we have to think about your goals and tasks for reaching these goals. When we will get the model we can compare our current processes and our model, we will see what we have and what we have not. After process description, we can write the plan for transfer from the current processes to the model processes.

Information about the process description will be in the next article.

I'll always glad to get your feed back and questions.

Posted on: April 08, 2019 07:28 AM | Permalink | Comments (9)

Some rules for successful requirements gathering

We know that IT system development is not only about the offer of automation services based on the requirements of the customer or consumers, but it’s about development business strategy, about business development.

For example, you have a shop, and when you created a web-site you have received a new market. If you are working in an international company which work with delivery shipments and you have created new technology about exchanges of shipment dates for your client, a big international company, you get a new market too, your business had gone to the next level because of the new technology. The new technology may give you possibility for work faster, with high quality and with new clients. And all of these examples about development both strategies: IT Strategy and Business strategy.

So, we need successful business analysis, including requirements gathering for this process as one of the main it part.

In the Business Analysis for Practitioners: A Practice Guide by PMI [1] the term Business Analysis is defined as “the application of knowledge, skills, tools, and techniques to:

  • Determine problems and identify business needs; 
  • Identify and recommend viable solutions for meeting those needs; 
  • Elicit, document, and manage stakeholder requirements in order to meet business and project objectives; 
  • Facilitate the successful implementation of the product, service, or end result of the program or project.”   

All of you know how many projects have fails, and these failures being attributed to requirements gathering, it’s almost 70% of all project failures [2].

How could we realize the right Business Analysis (or discovered requirements) and get the set of the right requirements?

It’s very important to see in the right direction (Figure). For determine problems and identify business needs we have to see around us, to find obvious things, and we have to use some set of rules.

Figure – Discover requirements

For my opinion, there are three most important set of rules.

The first set is about right questions when you try to discover problems and formulate requirements [1]. It is like a 5W1H (Five Ws and One How) method. Answers on these questions are considered basic in information gathering.  Therefore, in the business analysis we have also five Why. Here are some typical questions with why:

  1. Why is it the problem?
  2. Why is this situation happen?
  3. Why do you have this process?
  4. Why any alternatives are not work?
  5. Why the solution of this problem is so important?

In addition, of course, you have to remember to choose the right person as an interviewee.

The second set is about requirements management [3]:

  1. Planning how we could get the right requirements. Plan must include questions, on which you try to find answers (first set of rules), methods and instruments for work with them, list of sources, time, responsibilities, plan for integration, plan for quality assurance.
  2. Team work (Collaboration&Buy-In). All team member must be in the loop. You need gathering and work with all ideas no matter how crazy they can be. And you try to get support the decision from all team members. 
  3. Integration Management (work with changes). It's very important when you continue working, making changes and go-back iterations. It makes your result much better and clarify requirements.
  4. Quality Management (quality assurance). When you have a mistake in the requierements, it will be  cost up to 100 times in the future than it is to correct a defect early on while a requirement.

And the third set is about result analysis [4]:

  1. Be sceptic and always ask questions with “Why”.
  2. I mean especially very useful in the result analysis the McKinsey technic called MECE (mutually exclusive, collectively exhaustive). When you think in this way, you can find your gaps in the requirements and you can prevent duplicates too.
  3. Working with hypothesis: define, generate and test them.

In conclusion, to formulate the right requirements is a very complexity task, and there are a lot of information about different methods and tools. Above rules could be fundament in your requirements gathering.

References:

  1. Business Analysis for Practitioners: A Practice Guide, Project Management Institute, 2015, p.  
  2. Beginning at the End – Requirements Gathering Lessons from a Flowchart Junkie Cari Stieglitz, PMP, Project Manager, Faithful+Gould, Originally published as a part of the 2012 PMI Global Congress Proceedings – Vancouver, Canada
  3. Requirements Management 101 four fundamentals that everyone should know. Jama.Inc, www.jamasoftware.com | 1.800.679.3058
  4. Ethan M. Rasiel The McKinsy Way, Copyright 1999 Ethan M. Rasiel. Click here for Terms of Use, 188 p. 
Posted on: February 28, 2018 10:14 AM | Permalink | Comments (12)

How to quickly and efficiently align documents

Some of you know how hard could be to fix up with customer (especially in a large company) a lot of documents when they are part of your procurement. 

You have to correct them again and again...to have discuss them with a lot of people, which can have some different opinions about the same things, which can have some different interests. 

But how could you make this process working quickly?

I have developed a habit over the years of working in consulting to do the following things:

  1. To form a working group of experts, decision-makers in the case of a large project we need to establish several working groups.
  2. For each direction must be the person responsible for the direction and possessing powers of decision-making in contentious situations.
  3. Prepare the first edition of documents, and send them to the customer for given feedback.
  4. Give feedback from all of people which take part in the fix up.
  5. Write records of all observations in the table, record the answers to all remarks and add comments, especially if you don't agree with observation.
  6. Change documents and send them again to the customer.
  7. Organize meeting and discuss the documents, try to make the positive decision. 
  8. If the positive decision didn't find on meeting, you have to distinguish controversial aspects with description their solution ways.
  9. All final decisions must be agreed by the management Committee of this project and approved by the responsible for the project from the customer.

This is easily done when you have professionals in the field of project management, project office, and very difficult when they are not.

But some organizations don't follow project management processes, and they don't have project management professionals, techniques. And what can we see?

I was convinced on own experience, doing projects for two different large organizations. In one of them the specialists have been trained in project management according to PMBOK, the other heard nothing about it. In the first case, it was not difficult to organize the work properly and perform it easily. In the second case, it took some time on the organization of work on the project from the customer, as it was necessary to actually teach the ideology of project management and operation, as well as to overcome resistance and reluctance to change work style. But and one, and in another case, in the end, the process of working on documents was reduced to the mentioned steps.

I'll be glad to get your feedback.

Thank you for reading this.

Success to all of you. 

Posted on: November 23, 2017 11:55 PM | Permalink | Comments (13)

Scrum vs Kanban vs XP

At work I was being asked to say about differencies between Scrum, Kanban and eXtreme Programming. And I'd like to share my thoughts with you. 

  Scrum Kanban XP (eXtreme Programming)
Goal Use of cross-functional, self-organized, and empowered teams who divide
their work into short, concentrated work cycles called Sprints
To alleviate  impediments that cause us to take longer to deliver, not remove necessary pieces of the process. To organize people to produce higher-quality software more productively.
Date of birth In the mid 80’s, Hirotaka Takeuchi and Ikujiro Nonaka defined a flexible and all-inclusive product
development strategy where the development team works as a unit to reach a common goal. Scrum has
increased in popularity and is now the preferred project development methodology for many organizations
globally. 
Kanban developed in the 1940s as a subcomponent of the Toyota Production System and has its origins in these Lean and Just In Time (JIT) manufacturing processes. XP has been created  in 1996 by Kent Beck during his work on the Chrysler Comprehensive Compensation System (C3) payroll project.
Current state The Scrum framework can only be used for small projects. However, it can easily be
scaled for effective use in large projects. 
One of the reasons many groups implement Kanban is to figure out how to deliver more consistently. Kanban, as well as many other methods/processes, is often chosen and implemented by the management or leadership layer and the values and goals are communicated down to developers or other individual contributors. It's a very effective metodology for the small command programmers. Team size should be 5 or less people.
Speciality A key strength of Scrum lies in its use of cross-functional, self-organized, and empowered teams who divide
their work into short, concentrated work cycles called Sprints. Scrum is one of the most popular Agile methodologies. It is an adaptive, iterative, fast, flexible, and effective
methodology designed to deliver significant value quickly and throughout a project. Scrum ensures
transparency in communication and creates an environment of collective accountability and continuous
progress. 
In Kanban the workflow is visualised: work is broken down into small, discrete items and written on a card which is stuck to a board; the board has different columns and as the work progresses through different stages (e.g. ready, in progress, ready for review etc) the card is moved accordingly.
In Kanban the number of items that can be in progress at any one time is strictly limited.
Extreme Programming is successful because it stresses customer satisfaction. Instead of delivering everything you could possibly want on some date far in the future this process delivers the software you need as you need it. Extreme Programming empowers your developers to confidently respond to changing customer requirements, even late in the life cycle.Extreme Programming emphasizes teamwork. Managers, customers, and developers are all equal partners in a collaborative team.
Values 1. Focus
2. Courage
3. Opennes
4. Commitment
5. Respect
1. Transparency
2. Agreement
3. Balance
4. Respect
5. Understanding
6. Leadership
7. Collaboration
8. Customer focus
9. Flow
1. Communication
2. Simplicity
3. Feedback
4. Courage
5. Respect
Principles 1. Roles Guide
2. Empirical Process Control
3. Self-organization
4. Collaboration
5. Value-based Prioritization
1. Start with what you do now
2. Agree to pursue incremental evolutionary change
3. Initially, respect all roles, responsibilities and job titles
The principles that form the basis of XP are based on the values just described and are intended to foster decisions in a system development project. The principles are intended to be more concrete than the values and more easily translated to guidance in a practical situation.
Roles Core Roles:
Product Owner
Scrum Master
Scrum Team
Non-core Roles:
Stakeholders
Scrum Guidance Body
Vendors
Chief Product Owner
Chief Scrum Master
No existing roles. Some teams enlist the help of an agile coach. Tracker, Customer, Programmer, Coach, Manager, Tester. Anyone can be Doomsayer, Gold Owner (may be the same as the Customer)
Key metrics Sprint Velocity (2 weeks) Cycle time Iteration time (2 weeks)
Activities 1. Initiate
2. Plan and Estimate
3. Implement
4. Review and Retrospect
5. Release
1. To Do
2. Development
3. Test
4. Release
5. Done
1. Planning
2. Managing
3. Designing
4. Coding
5. Testing
Practices 1. Planning
2. Daily Scrum
3. Review and retrospective: Sprint Review and Sprint Retrospective
4. Extension: Backlog reinement and Scrum of Scrums
5. Artifacts: Product Backlog, Management, Sprint Backlog, Product Increment, Extensions (Sprint burn-down chart, Release burn-up chart)
1. Visualize
2. Limit Work-in-progress
3. Manage Flow
4. Make management policies explicit
5. Improve collaboratively (using models and the scientific method)
Extreme Programming has 12 practices, grouped into four areas, derived from the best practices of software engineering:
Fine scale feedback:
Pair Programming
Planning Game
Test Driven Development
Continuous process:
Continuous Integration
Design Improvement
Small Releases
Whole Team
Shared understanding:
Coding Standards
Collective Code Ownership
Simple Design
System Metaphor
Programmer welfare:
Sustainable Pace
Change philosophy Teams should strive to not make changes to the sprint forecast during the sprint. Doing so compromises learnings around estimation. Change can happen at any time. A high degree of developer discipline along with continuous customer involvement for the duration of the project. 
Cadence Regular fixed length sprints.  Continuous flow. Iteration.
Release methodology At the end of each sprint if approved by the product owner. Continuous delivery or at the team's discretion. At the end of iteration.

So, there are different methodologies you can use to manage project.
I think the main weakness in all these methodologies is poor knowledge about product. And sometimes we are trying to develop existence products when we need to create new system.
We need to choose methodology or to combine methodology tools in depending from kind of project and its scope. We need to take cognisances of experience, qualifications and conditions.

 

Posted on: October 07, 2016 12:21 AM | Permalink | Comments (13)
ADVERTISEMENTS

"More than any time in history mankind faces a crossroads. One path leads to despair and utter hopelessness, the other to total extinction. Let us pray that we have the wisdom to choose correctly."

- Woody Allen

ADVERTISEMENT

Sponsors