How do you manage WBS brain fatigue?

There are a few things you can do for a new perspective.

Take a walk, or work on something else for a while. When I stare at a problem for too long, I tend to keep following the same mental pathways and reaching the same conclusions. If I go for a walk or do something else for a while, suddenly the different perspective makes new ideas pop into my head. I do some of my best thinking when I'm not trying to.

Create some different perspectives of the project itself. In the systems architecture world, there are a variety of "views" often created like the Operational View and the Capability View. If you look up the DoDAF "viewpoints" you will find a number of different perspectives to consider and spark ideas. These are also very useful to discuss with the stakeholders before you go too far. I've seen many projects where people created a bunch of functionality that wasn't really needed, but missed what the stakeholders really wanted.

First thing to do is understanding that all related to the project must be created from all related to product. I mean, project scope is defined from product scope. Business analyst is accountable for product scope. So, request from business analyst the product scope.

Hi Brigitte .

I am assuming that you are highly technical and knowledgeable at what you do, being an engineer and therefore understanding the technical aspects of projects may come naturally to you.

However, this is a project where you need the assistance from a number of people to make sure that you nail down the scope of your project as accurately as possible.

A Work Break Down Structure would be of most assistance to create your scope items.

Please forget about MS Project and Project Tasks / activities until you have clearly nailed down what your project and product scope is going to be.

Break your work down into Product versus Project Scope

You need to know everything that goes into building an application from :-

Requirements Specifications
Design
Support Plan
Implementation
Release plans
Application Patching Regime
Operation System Patching Regime
Business Continuity Plan
Business Impact Assessment
Privacy and Security Impact Assessment
Test Plan
Test Summary Report
User acceptance Testing
Decommissioning Plan
Data Migration Plan
Procurement Plan

Your Project scope would include things like
Business Proposal
Project Management Plan
Project Schedule
Project Risk Register
Project Issue Register
Stakeholder Register
Communication Plan (if not already a part of the PMP)

You already have an application that needs to change, therefore you need every product related document to be created new or changed.

My advise is for you to meet with your Delivery team (testers, technical lead, BA, support) in a brain storming session and to come up with scope items relating to the Product Scope and whatever else they can think of.

Present your 150 items or so in a hierarchical structure to them and let them add/modify/improve your current understanding

Create a work breakdown structure using post it notes and when you are happy with all the items , you can transcribe it into Visio.

Next step is to break down the individual scope items into activities , after which they will be small enough to put into MS Project.

Once you have your WBS in several levels , you can slice and dice however you would like to do your management reporting.

And remember that your MS Project schedule doesn't have to be War and Peace.

Planning is all about progressive elaboration. Your main task is to answer the following questions asked by management :-

How long will this project take?
Whats the work involved?
Who do you need in your team?
How much is it going to cost?
What is the project going to achieve?
What are the risks if we don't do it?
What are the benefits if we do it?