Planning a Technical Project-Too Many Good Things

I recently had a little discussion with a friend of the technology consultant. The friend knows that he cares about the contract details and details that support the projects plan and technology contracts. We notice that we are talking about an economic principle called the Law of Reduction of Marginal Economic Profit. His point is that for project owners in the process of planning collection requirements for new projects, materializing specifications, researching user preferences, etc., the law of lowering marginal returns is set much sooner than they realize. It was that The resources you spend in the early planning stages can generate significant returns. But shortly thereafter, it spends the same amount of resources again, and then the next time it makes even smaller profits. When catching up with the planning process, it is often difficult to identify when the cost-benefit curve begins to flatten.

I accepted his theory because what my friends said seemed plausible and I had no evidence of opposition. Then considering the possible consequences of his theory, I said, “Aren’t you going out and starting to spread this idea to the tech community?”

Threatened Evangelist:

This was my fear. Here, I am an evangelist of this content and detail, and by telling people across the table that technology project planning and critical thinking is less necessary, but more than that, There were companions who could weaken the past and future evolution of the mission. After all, the project owner’s plans and ideas generate the content and details that I have come to desire and respect.

Well, we talked a little more, and my friend added some explanation. After all, he mainly suggested that project owners not waste time and money on planning what they couldn’t effectively plan at a particular point in time. Makes sense. I was still calm, but now I’m a little relieved.

Clear Example:

We decided to use a stepwise or iterative approach for our next project. Buy off-the-shelf software and customize quite a bit. Phase 1 involves extending individual elements of existing functionality and connecting to a live database for some testing.

In this example, we aren’t really going to consider the details of Phases 2-5 or estimate the costs within those phases. The cost never reaches the subsequent phase. 2. We have not yet tested the cost assumptions within Phase 1. In fact, I probably chose the iterative approach for this project because I can’t effectively plan the project from start to finish.

Less Obvious Example:

A friend and I talked a bit more, and we have gone beyond the obvious example, the acceptable one. My natural reaction was to resist further expansion of his theory. Because I knew that he would come closer and closer to my bones and threaten the root of my missionary mission. But sitting before me was a bright, clear thinker with nearly 20 years of technology experience. I had to listen (nervously). “When the students are ready to study, the teacher will show up.”

Gathering requirements-good and arguably what professionals have encouraged us to do more in the last decade. We have come to believe that more than “insufficient requirement development, which is cited as the main cause of project failure.” While there are times when more requirements are useless (and even potentially harmful), experts do not teach us how to determine when we are around the corner.

Spec development-same story. Fully develop the specification now, or risk the failure of your project.

User settings-same story. Involve users in the planning process. Otherwise, “When you build it, they don’t come.”

I’ve heard so much preaching on these topics that there can be a lot of clichés about each topic. The advice was pretty good, but I’m kicking it out for each article, speaker by speaker.

Settlement:

Not only did I resist this flow of discussions with my friends, but I must admit that what he said makes perfect sense to me. But now I needed to find a way to coordinate two different concepts. On the one hand, a long-standing belief that more project planning and critical thinking is always a hope, and on the other hand, many of my cognitive good things that you can really have.