[1/3] The Art of Project Management (The art of managing IT projects) (Category Management)
This is one of the first project management books I read early in my career. The book was written by Scott Berkun in 2005 year, and in 2007 It was translated into Russian by Peter Publishing House. At this time, I was graduating from university and we had a separate subject "Project Management", which the guys from SOVNET told us. (It is the Russian part of the International Association IPMA). In general, the guys were quite formal and I wanted to learn something more technological without a raid of state projects - so I came across this book and did not regret it. Scott has written a book about the results of his 10 During his years at Microsoft, he started as an engineer and then moved to the position of program manager. In this role, he worked on Microsoft Office, Visual Basic and the predecessors of Internet Explorer. 6.0 (punk).
The book itself is still relevant in some places, but only experienced guys who wrote code in those days can understand references to engineering processes:) The book consists of four parts, and here we will discuss the first two:
- Part 0. Preface
- Part 1. Plans
- Part 2. Skills
- Part 3. Management
Part 0. Preface 1) A brief history of project management (and why you should care) Scott tells us that project management has been with us for a long time, but it wasn't called that before.
Part 1. Plans 2) The truth about schedules Panning and calendar deadlines aim to close three goals
- Set deadlines
- Identify project participants Create a tool to monitor the project Remember that plans are a probabilistic story. Plans themselves are created using a divide-and-conquer approach, and high-risk work is planned primarily to reduce the uncertainty of plans.
3) How to figure out what to do The project should be viewed from three points of view: businessman, engineer and consumer. Business - how we will make money on this project (PnL)
- Engineer - how we can design and implement the planned Consumer - what exactly the consumer needs, or rather what set of features should be in our product In order for the project to succeed, it is necessary to balance these three views, and then fix them in the form of separate documents - here the author gives rather heavy examples of artifacts that were popular then. (market requirement document, work brakedown structure)
4) Writing the good vision Here, Scott talks about creating a good concept that should be simple, purposeful, inspiring, able to consolidate and rememberable:) Scott believes that a good concept has only one author. It is desirable to make a brief and capacious concept, and not voluminous and blurred.
5) Where ideas come from The author discusses the gap between problems and solutions. Here, the author talks about creativity and recalls divergent and convergent thinking. He issues theses that answer the question in the title of the chapter. Good ideas come from good questions. It's about the same as a good question -- it's half the answer. Good ideas come from bad ideas. A lot of good ideas lead to a good project. Design often starts with the consumer, not the technology.
6) What to do with ideas once you have them Generation of ideas is cool, but the main thing is not to get carried away. Initially, new ideas should be grouped into similar ones and tested on prototypes. As the project progresses, there is less room for experimentation and change, so incoming ideas can be memorized until the next project:)
Continuation at the following posts
#Management #Agile #Project #Leadership #SelfDevelopment #Software #Processes