Hello and welcome to another penetration. Testing, execution Standard discussion. Today we're looking at part two for metrics for time estimation. So picking up where we left off, we're going to get into understanding picks, fee versus hourly considerations, understanding the drop dead date
and understanding areas and times were testing extensions may be necessary.
So with that in mind, let's go ahead and jump right in. Let's talk about some pros and cons real quick of fixed fee versus hourly rate and how these estimates workout.
So starting on the left with fixed fee. Some pros here are that it's scalable in that if you have maybe one or two s Emmys that do, quoting within an environment where you have someone that looks at a project and comes up with a potential cost,
um, this makes it to where you can get a lot. Maura out the doors for his potential opportunity. If you're in an organization that is providing penetration, testing their security testing is a service.
It's great for the client because the number you give them is the amount that they pay a lot of cases. Fixed fee structures include expenses, which is why it's important to properly estimate, you know, expense cost. When you're looking at a fixed fee structure,
you could add a line item that,
you know, expenses on a part of a fixed fee structure and that can take care of that peace. But that should be minimal compared to the overall cost of the project for the client. And then the client doesn't have to approve every hour in the project. And so we'll talk about some cons of hourly rates. Which kind of feed into that
some fixed be cons is that your scope of work may need to be generic. So it's really, really and it is up to you. But when you're doing fixed fee work, I like to use a kind of generic scope to determine. Hey, look,
if you only want to pay this much, this is what your scope looks like. This is the testing will do. This is what we look at. This is how we approach it.
You know, this covers this many assets within the scope of service,
and that kind of makes it again scalable and and kind of efficient in that respect. Um,
and then, you know, again, the con here is you can build and that additional expenses are not paid by the client. Everything's covered in that fixed fee that for me, though, when I try to do fixed me, I try to make it all inclusive. And so if I do run, intending on
accounted for expenses that is a con with fixed fee.
Now some hourly pro here is that the client is built for every hour worked. So if they want you to go, you know into something that is not originally scoped.
If that can be covered with approval from them
and you can continue working on the project and they're fine with being billed,
then that's a win. Some cons is that the client may put a cap on the total hours. And so let's say that you know it's going to take, you know, an estimate of 40 hours to do. Let's just say a network penetration testing external penetration test with maybe some light social engineering.
Let's just say you come up with a number 40 to 80 hours, and the client says, like I'm not going to be able to give you a buck over 50
hours in this case that could be kind of detrimental to your ability to scope the work, to meet kind of what you think would be best practice. And so there's always that conflict of wanting to
bring in the work to ensure that you're covering man hours that you're covering, you know, overhead and things of that nature.
But, you know, that's part of that hourly discussion. And then the client may micro manage the project. And so this this kind of plays into complicated invoicing and things of that nature. If you've got a client that is obsessive about you tracking every single hour of the project, which
if you've got a system in place shouldn't be too hard, you should be able to easily,
um, you know, track time and do things that nature. And, you know, there is software out there for that. But a client may want to know. Hey, you said you spent eight hours today doing vulnerability analysis and you know, kind of feasibility review of, you know, these potential attack vectors.
But you didn't lay out our by our exactly what you were looking at in doing In that analysis
that can become cumbersome and very much a con when it comes to working on an hourly rate.
Now let's talk about drop dead dates and the importance of those. So this is the last date in which action can be taken. It is the date by which something important must be done. So this is a double edged sword. I like to think of a drop. Dead date is a way to keep both parties accountable.
It's great for ensuring the client stay on task and meet deadlines.
It overall improves accountability within the project in the process. Great for forecasting your team's workload.
And generally I would want a drop dead date to be accompanied by contractual clauses that both parties are protected by. So
there could be something in a contract that indicates, hey, you, as the consumer of our service, have a responsibility to replied, tow us in a timely manner after project initiation, to provide access, to provide documentation to provide feedback on particular questions.
And if you don't do so, then you know we will make, um, you know, um, maybe best practice assumptions on certain things, but we can't then
have that report reflect an accurate depiction of the environment or there may be up charges that we would provide because now we have to spend more time on the project of its fixed fee. Whatever the case may be. Or you may say that look, the project starts as of the first of next month, and we planned for it to be done by the 28th.
And if the project we find is reasonably done by then and there were other things that you wanted to add to it by that point, then we have to re negotiate additional fees and things that nature. But the initial deliverable will be done and we'll expect payment. However you wanna play that drop. Dead dates are very great ways to keep you from
signing an engagement, putting work on the books and then at the end of what should have been a three month engagement. Your client is now engaging you,
and you've missed out on other opportunities or scheduled those further in the rear
because you thought you would be working on this initial project. So these air definitely a great way to predict with you and your clients in the process,
and then that gets us into testing extension scenarios, and so I'm not going to get heavily into this. But I would consider it when a client hasn't agreed upon hourly rate and we'll pay to have the work done with a co signed or a countersigned scope, meaning that you don't go off their word
and, you know, via email what they want you to do in addition to a scope you right up in addendum amendment. Whatever the case may be to the scope with some additional fee structure that is signed off on by both parties and agreed upon said that you're still protected legally from any
issues that may come up from. You know, that original scope deviation.
This is great for additional time when it's needed for testing. Client has requested remediation assistance, and you don't want to leave them high and dry, and you want to provide that extra help. Client needs more detailed write ups and recommendation again. So this is great win. We're on an hourly schedule. Hourly rate were not fixed fee or maybe we are fixed the
but it wasn't covered in the initial scoping. Now your client is wanting an extension of that working additional assistance
now when you can potentially decline is when the client determines they do not wish to pay additional fees to cover work outside of the scope.
Now that is again, potentially because you are ultimately the party that will make the decision on what you think is best for your client relationship. If this is a long term relationship, they pay you on a monthly basis. You consult with them regularly. Maybe, you know there's there's other
work that they've provided to you through third parties or other businesses that you've been able to do testing for, and you want to help them
provide the extension. You know, keep that relationship going. So that's really case by case scenario,
and you should always consider thes types of things and have kind of a plan in place to address when a client may want an extension on the work.
All right, everyone. So with that, we looked at fixed fee versus hourly considerations. We looked at and explain the drop dead date, and we looked at evaluating circumstances for extending testing scenarios. So with that in mind, I want to thank you for your time today, and I look forward to seeing you again soon