1

I have no experience in scoping things. The projects I've worked on since I've started have been scoped and I just do what is asked in the stories and features. My current task is scoping an upcoming project. This is a 16 year old, 500k+ line app.

How do I begin scoping a project I have little knowledge of? I do not have much experience in the multiple apps it will affect. I'm overwhelmed and would just like a general process/tips on how to effectively scope something without missing major parts.

I have one expert engineer on our team but he really is busy and very begrudgingly responds when asked things. I try to keep my questions to 1 every 3 days, so I group them. When I asked how to scope this, or in general where to start he just said open the code base and determine the hours for the project.

MCW
  • 8,718
  • 2
  • 28
  • 48
Testmouse
  • 11
  • 1
  • Do you have a mentor? Have you asked him/her? – Sarov Sep 26 '18 at 21:21
  • Not really. I have one expert engineer on our team but he really is busy and very begrudgingly responds when asked things. I try to keep my questions to 1 every 3 days, so I group them. When I asked how to scope this, or in general where to start he just said open the code base and determine the hours for the project. But it's a 500k+ lines 16 year old app, etc. I just dont want to mess up so I wanted more advice. – Testmouse Sep 26 '18 at 21:44
  • This question is quite broad. How are you defining scope? What constraints were you already given? Is the scope you are to define part of a larger scope project and / or a project that is already underway? There is more to the story you need to define here. – David Espina Sep 27 '18 at 12:14
  • 1
    One very good piece of advice given to me years ago was to start with what finish looks like, then work backwards from there. – David Espina Sep 27 '18 at 12:16
  • What does "scoping" mean to you in this context? Without an understanding of your role, and of what the expectations actually are, this question does not provide enough information to elicit a canonical answer. Please improve the question so it can be re-opened by the community. – Todd A. Jacobs Sep 28 '18 at 13:00
  • You specifically asked how you begin. Since it's an existing application, I would begin by enumerating all the major sections of the application, then break those sections down a bit further. The more detail you get, he more accurate you can be. You may need help identifying backing features. I would then identify interactions with other systems. You can then review the various parts with your dev/bos/ – Robert Paulsen Sep 28 '18 at 19:49

3 Answers3

2

You need to clarify expectations of you. Both from the senior dev, and, more importantly, from your (presumably shared) boss.

I have one expert engineer on our team but he really is busy and very begrudgingly responds when asked things. [...] When I asked how to scope this [he told me a way that's almost guaranteed to fail].

You should speak with your boss, and clarify which of the following is true:

  1. The senior dev is expected to spend more time than he currently is mentoring you. It's also possible that you're reading more into the senior dev's reluctance than he intends to convey. You should consider talking to the senior dev first.

  2. You're expected to fail. They want you to go out, flounder, fail, and learn, so that you do better next time.

  3. You're expected to succeed without sufficient guidance. In this case, I would suggest polishing up your resume so that you're ready to leave (ideally before things hit fans).

Sarov
  • 14,768
  • 5
  • 33
  • 62
1

I would suggest scoping your project with any early validated learning you may have going into the project. Basically, just get started and use empirical evidence you gain from users to incrementally build out requirements as they emerge. A prototype will be more helpful than an entire project that was built to spec without any feedback to serve as catalysts for additional features.

Trying to scope out too much too early is a big risk. if there’s a vision and/or existing codebase for the project, taking those pieces to create hypotheses to test with users is a valid route. Requirements will emerge over time and being able to plan just-in-time work based on feedback will serve you, your project, and your clients well.

dom_michalec
  • 940
  • 4
  • 10
0

When you "scope" a project, when you evaluate what needs to be done, who will do it and what is going wrong; it is important to separate the technical side from the management side of what you have to do. First, you must be aware of the trap of solving technical problems one after another, without having a plan; and arrive, at the end of your project, facing the same dissatisfaction as in the beginning. I would begin by reading complaints done by the users of the app and their suggestions of improvement. I mean all of them. After, I would talk to my boss to know what he or she find wrong with the app: what are the complaints he or she received from users, clients and employees, your co-workers. I would discuss the budget you can have to correct the problems and to hire new employees if needed. I would ask for the deadlines: how many weeks of months do you have to fix things or to propose an innovation. That's what I call the management part of your situation. In our community, questions have to be technically oriented. Some moderators don't appreciate management lessons, even given by a MBA like I. But, if you do those simple steps, you will be well equipped when you will face the wall of silence of those who don't want to help you or of those who feel they could lose their job or their influence in the company you are in if the app is modified or even deleted. When your boss knows what is going on and what you are trying to do; when he or she has a fair ideas on how long it will take and how much it will cost; you are more backed than arriving at the end of you project with a lot of unwanted surprised to your boss. You will earn the respect of you employees/team members when you will prove to them that you master the technical side of your project too. In our community, the moderators want technical questions about the usage of project management software programs. You can asked new questions when you will me at the step of modifying the app you are talking about. I am not very well liked in this community when I give answers like that, because I give the true secrets of a successful project management. The technical side is secondary. You need employees in your team that are not afraid to put all their cards on the table and to tell you honestly what is going wrong and were are the bugs, without fearing for their reputation and their career. I am in this community since 2012 on and off. In Silicon Valley, every body want to be the next big thing and they steal you happily stuff; but they rarely help you, even if it is their job to answer the question of their boss.