Managing Personal Scope

ArgonDigital - enterprise automation experts

Share This Post

The nature of our work contributes to long hours and a hectic pace on projects. Our culture promotes work/life balance and “normal” work week hours. How does a company resolve these seemingly contradictory objectives? We manage what I like to call “personal scope”. Personal scope comes in two formats: I have too many individual tasks on my list and I can’t get them all done; and I have one task but to accomplish the task by the deadline I would have to work around the clock. Most of us have experience with the first personal scope situation and have developed our own styles and methodologies for handling it. Make a list. Order the list by importance. The items at the bottom can wait for another day or be passed to someone else. The second personal scope situation is harder.

Let’s say company X wants to build the Empire State building and has hired ArgonDigital to write the requirements documents. Monday morning consultant Bob shows up to kick off the project. The customer contact tells Bob, “We have to have the document by Friday for the contractors.” Bob may protest. He may make excellent arguments for why that’s not possible. But, in the end, the customer is always right. Bob must produce something to meet the customer’s needs in 5 days. How can Bob produce requirements the customer will find valuable and complete and still only work 40 – 45 hours this week?

Bob, can take a lesson from a May blog post called “The Magic of 7 – 9” (https://seiblog.wpengine.com/2006/05/magic-of-7-9.html) to ensure he adds value for the customer and doesn’t work himself into the hospital. The customer has indicated he needs a requirements document by Friday. Clearly the requirements for the Empire State building cannot be completely written by Friday. However, Bob should be able to define all the areas in which requirements will be needed and then further segment those high level areas into features and then requirements. Let’s explore this method of working normal hours and accomplishing a tremendous amount of value-add for the customer.

Bob realizes he can’t start asking all the stakeholders what’s important about the project without some methodology for capturing the information in a way that he can make sense of it quickly and effectively. Bob decides to take a first pass before he meets with anyone. Let’s brainstorm 7 – 9 areas in which Bob may need requirements. First, we look outside the building. Perhaps he will have requirements about what the building looks like, the parking, the safety features, the regulartory requirements, and the landscaping. On the inside, the document may need requirements that cover the layout and physical terrain, the environment and ergonomics, and the ambience / style imparted to a visitor.

Bob now has a list of 8 high level categories in which he must provide requirements to consider the document complete. At this stage, Bob has established the realm in which he will work. As he begins his first round of interviews to gather requirements he can categorize everything his stakeholders say to determine if he has good categories. He can also use his categories to remind the customer of areas he/she may not have thought of yet. Next, Bob schedules his first round of interviews. He meets with several stakeholders over the course of Monday and Tuesday. He now has mountains of information capturing ideas the stakeholders have about the building.

Bob can take his next cut using the 7 – 9 principle. In each high level category he identified he can take a look at the interview feedback and start selecting 7 – 9 features for that category. Let’s take the category ambience. Based on his interviews, Bob knows that many stakeholders want the building to feel warm, inviting, and rich, much like a law firm might. Bob thinks about places he has visited with this kind of ambience and the kinds of things that affect it: lighting, colors, materials, furniture, and wall decorations. He now has 5 sub-categories for ambience. Once he has fleshed out the sub-categories for each high level category, Bob may discover he’s ready to start writing requirements. He may discover he needs another level of specification.

The reason this approach helps Bob control his hours is he can stop at any level and he has a complete document. He has covered all the areas in which requirements may be defined to the specificity he can within his time frame. Bob has chosen breadth over depth. In a short timeframe, breadth has to come first. Bob may not have the final level of detail needed to build the Empire State Building, but he has added value by giving the customer a frame work around which requirements can be gathered. He has given the customer a document that speaks for itself in terms of next steps. Essentially, Bob has written the cliff notes of the requirements for this project.

Bob will probably have to continue digging deeper into each category, sub-category, and feature until he gets the final requirements documented. However, an approach that treats requirements like an onion, peeling back one layer at a time, rather than digging to the deepest level on one item and then moving to the next item, gives Bob the ability to control the scope he takes on each week. At any point in time, Bob can turn in a “complete” document. It may not be final. It may not be as detailed as Bob’s personal standards require. But it will be complete and will add value for the customer.

More To Explore

b2b auto pay

B2B Auto Pay: Automation Use Cases

Migrating a B2B “Auto Pay” Program Companies migrating to SAP often have daunting challenges to overcome in Accounts Receivable as part of the transition. You might have different divisions running

ArgonDigital | Making Technology a Strategic Advantage