⚙ 👐 🎭 index - references
Devops - Business Proces Management
Contents & topics PM
PM by my personal experiences
Transforming the way of working is a goal on its own. At least that is my personal experiences.
I don´t believe that it is the intention, only not knowing better options to achieve change eliminating unsatisfying dillemma´s.
The one that is dropped first is: "Business"
Too fast .. previous
| Reference || Topic || Squad |
| Intro ||PM by my personal experiences ||01.01 |
| PM references ||Project management Generic ||02.01 |
| PM critics ||Critism Project management ||03.01 |
| ICTPM ||ICT project management ||04.01 |
| ICTPM critics ||Critism ICT Projects ||05.01 |
| ||Unhappy on what is going on. ||06.01 |
| 7W´s ||Missing links - related to the 7W´s ||07.00 |
| ||Naming Conventions. ||07.01 |
| ||Software Life Cycle mangement. ||08.01 |
| ||Security (business: logic - data). ||09.01 |
| ||The meaning of "The Application". ||10.01 |
| ||Data governance. ||11.01 |
| What next ||Ending a journey. ||12.01 |
| ||New journeys to enjoy. ||12.02 |
- 2019 week:16
- This chapter picked some old pictures and put in two new references.
- Having to do: what is usefull from old pages, what to added.
Project management Generic
The primary challenge of project management is to achieve all of the project goals within the given constraints.
This information is usually described in project documentation, created at the beginning of the development process. The primary constraints are scope, time, quality and budget.
There is a big market for management advice. A generic starter:
The ideal skill set — the Talent Triangle — is a combination of technical, leadership, and strategic and business management expertise.
At complicated situations everybody can be right, form his viewpoint. Viewpoints being that different they can&acutt be true both.
Other words, hypes, working approaches: Scrum, Agile, Lean six sigma, Kanban
Critism Project management
What the frustrations are, the best is by infographics.
The Dead Horse Theory
- Buying a stronger whip.
- Changing riders.
- Threatening the horse with termination.
- Appointing a committee to study the horse.
- Arranging to visit other countries to see how others ride dead horses.
- Lowering the standars so that dead horses can be included.
- Re-classifying the dead horse as "living impaired".
- Hiring outside contractors to ride the dead horse.
- Harnessing several dead horses together to increase speed.
- Providing additional funding and/or training to increase the dead horse´s performance.
- Doing a productivity study to see of lighter riders would improve the dead horse´s performance.
- Declaring that as the dead horse does not have to be fed, it is less costly, carries lower overhead , and therefore contributes substantially more to the bottom line of the economy than doe some other horses.
- Rewwriting the expected performance requirements for all horses.
- Promoting the dead horse to a superviory position of hiring another horse.
Another famous one.
- A clear overkill by managers micromanagement.
- Blaming the worker not fullfilling unrealistic expectations.
- Rewarding managers for the excellent peformance.
Of course there are a lot more than those. What is not mentioned in these two infographics is:
- Lack of coöperation by not shared business goals (silo´s).
- Not willng to change with correct effective working innovations.
ICT project management
The change in managing ICT is a fast continously change.
The Design Thinking process first defines the problem and then implements the solutions, always with the needs of the user demographic at the core of concept development.
This process focuses on needfinding, understanding, creating, thinking, and doing. At the core of this process is a bias towards action and creation: by creating and testing something, you can continue to learn and improve upon your initial ideas.
The design thinking process consists of these 5 steps:
Agile Modeling (AM) is a practices-based software process whose scope is to describe how to model and document in an effective and agile manner.
The practices of AM should be used, ideally in whole, to enhance other, more complete software process such as eXtreme Programming (XP),
the Rational Unified Process (RUP), Disciplined Agile Delivery (DAD), and the Enterprise Unified Process (EUP) to name a few.
AXELOS is responsible for developing, enhancing and promoting a number of best practice frameworks and methodologies used globally by professionals working primarily in IT service management, project, programme and portfolio management and cyber resilience.
These methods, including ITIL, PRINCE2, MSP and our collection of cyber resilience best practice products, RESILIA, are adopted by private, public and voluntary sectors in more than 150 countries to improve employees skills, knowledge and competence in order to make both individuals and organizations work more effectively.
Cap Gemini SDM, or SDM2 (System Development Methodology) is a software development method developed by the software company PANDATA in the Netherlands in 1970. The method is a waterfall model divided in seven phases that have a clear start and end. Each phase delivers (sub)products, called milestones.
- EMPATHIZE: Work to fully understand the experience of the user for whom you are designing. Do this through observation, interaction, and immersing yourself in their experiences.
- DEFINE: Process and synthesize the findings from your empathy work in order to form a user point of view that you will address with your design.
- IDEATE: Explore a wide variety of possible solutions through generating a large quantity of diverse possible solutions, allowing you to step beyond the obvious and explore a range of ideas.
- PROTOTYPE: Transform your ideas into a physical form so that you can experience and interact with them and, in the process, learn and develop more empathy.
- TEST: Try out high-resolution products and use observations and feedback to refine prototypes, learn more about the user, and refine your original point of view.
Critism ICT Projects
What the frustrations are, the best is by infographics.
Swing Tree project
The classic one. Seen already in the 80´s and never got outdated as legacy.
Brooks observations are based on his experiences at IBM while managing the development of OS/360.
He had added more programmers to a project falling behind schedule, a decision that he would later conclude had, counter-intuitively, delayed the project even further.
He also made the mistake of asserting that one project—involved in writing an ALGOL compiler—would require six months, regardless of the number of workers involved (it required longer).
- How the customer explained it
- How the Project Leader understood it
- How the Analyst designed it
- How the programmer wrote it
- How the Business Consultant described it
- How the project was documented
- What operations installed
- How the customer was billed
- How it was supported
- What the customer really needed
The tendency for managers to repeat such errors in project development led Brooks to quip that his book is called "The Bible of Software Engineering", because "everybody quotes it, some people read it, and a few people go by it".
The book is widely regarded as a classic on the human elements of software engineering.
Unhappy on what is going on.
Sometimes you get a feeling there is some path still to go, you are not at the real destination yet.
Not really aware what it is until gettting some hints and a little bit being hurt.
Summarize - Explanations
Only a summarize what is bothering me is given here under 7w´s.
The explanations are in the many detailed documented design topics. There are ideas in those not common mainstream, rather disruptive.
As an illustration can say much more than a lot of words, I included many illustrations.
Any elucidation when needed can be done on request.
Missing links - related to the 7W´s
Having well defined set of names associatied with their types and meaning (metadata) is making a technical realization easy.
It would be even far better having a generic standard approach for that.
It is something I have never seen an attempt within the ICT. Document systems: archiving, connecting to busienss workflows are existing.
Why don´t they exist in the software development workflow?
Starting a local attempt:
Naming standard like ibrarians have a succesfull approach. Includes the Intial end End of life stages with versioning
As those namings conventions aren´t generic, porting the solution to another environment is almost impossible.
Changing a technology can be a business requirement.
The implementations can be continued without a generic nameing convention using an in house local one that based on tools that are convenient available.
Software Life Cycle mangement.
Every enviroment has his omn approach on the Life Cycle Management of hardware, operating system, tools - middleware , business applications.
The confusion on the meaning of "the application" is mentioned seperately. The consequence is that is impacting the release management in several ways
There are many dependicies between those .
Changing the OS layer can impact the behavior of tools - middleware causing unexpected undesirable results at the business applications
Changing the tools - middleware layer can cause unexpected undesirable results at the business applications
Needing new features within tools middelware for development for the business it would the best thing to do to change the acceptance (regression testing) and production environmet as first steps after the proof of the installation setup in a infrastructural environment.
That is not the Develop Test Acceptance Production order of the business applications.
Security (business: logic - data).
Risk management and security policies are not very well accepted activities as strategy and tactic. They are however high level business requirements by regulations and can´t be ignored
Security of the assets of the business is too often seen as something technical where no accountability exist within the business
Actions by the ICT department pretending to be in security control
Make the business responsible for the security guideline. See ICT staff as enablers data processor not as data controller (GDPR)
When doing user access management instead of Information Access Management (IAM) the access of business assets by service - and high privileged accounts are getting lost
Important business information assets are left vulnerable at the technology layer in many ways.
Design and implement security access for tools middleware
. Dot that in alignment with the well know user access management approach.
The meaning of "The Application".
What does somebody really meain by the word "the application".
The answer is in Who onWhat When. For most people a computer application is just a black box offering results on input.
Within ICT it is less obvious, we have:
- hardware (physical components, the box)
- operating system (being programs, code)
- tools - middleware (being programs, code)
- business logic (being programs, code) - data (information)
The word is an adjective on what is used on. Each of the higher order one can be seen as being an application of the former.
Confusion is problematic
Hardware, operation system, anything else: "the application".
Business "the application": that is only business logic - data.
It does not go well for the tools, middleware.
Use different indicators and words for the layers:
- business logic - data.
- tools middleware
Business logic (code) and (information) are important assets. They are to be governed, data governance for the information.
The operational area is a well known area. The challenge is in improving operational business processes using analytics.
Process Innovation, stable operations
Seeing the operational environment completely isolated from innovation request underpinned by analytics will result in blocking processes and/or innovations.
See the data warehouse data lake as their physical representations.
A solution for in time availablity of resources in the logistical chain.
With "just in time" JIT delivery there will be no need for storing. The concept is Streaming data (lambda architecture).
Copying information to another location is called "datawarehousing" modernized "data lakes".
Historical there is no security concept access included, although is should be present.
The datawarehouse concept is based on the assumption NO information will brought back to operations.
That makes no sense (see dwh data lake).
Ending a journey.
I used this picture at the end of chapters, intention: following a logical sequential order.
This picture is personal (holidays). An entrance and exit of Monemvasia, laconia Greece.
Being both, the single pathway (the name in greek) it is unclear whether it is the start or an ending. 👓
As long as I am updating chapters somewhere, there is no end.
👓 Restart at high conceptual level
New journeys to enjoy.
In the agile world, using the scrum syntax, the work is decribed as a "customer journey". They can be never ending stories.
At some time "no work" is the objective goal, going for a private journey, better described as holidays.
To be repeated predictable over and over again. Not really boring wiht this kind of feeling.
It is a holiday picture made at Lakka Paxos Greece. The transport and sleeping place being the place at home in the right corner with the colored fancy fish in the aft.
During the journey doing "sprints" by going from one place to another.
⚙ 👐 🎭 index - references
© 2012,2019 J.A.Karman