Dennis DavisConsultant| Davis ConsultingAntioch, Ca, United States
OK, first let me apologize up front if this topic has been beaten to death in other discussions but I haven't come across the exact solution to my problem. In a nutshell, I'm helping to institute a new SDLC model for company complete w/ templates, processes, etc. I'm jumping into the middle of the project and evaluating the usefulness of some of the templates and how to modify them to be more useful. In particular, the templates for the company's BA include: 1) business requirements and 2) functional spec.(one version for use cases and one version w/out use cases). Now, my question is twofold:
1. Shouldn't the use cases in the truest sense, be part of the bus. reqs template since its a method of gathering functional reqs?
2. If I do re-buld the bus req template to incorporate use cases, is there a real need for a functional spec?
I hope my questions are clear enough to elicit some good responses. I've worked on projects that have used everything from use cases to SRSs to functional and/or tech requirements docs but this is the first time that I have had to truly consider what is the purpose for some of these docs. Thanx for the responses. Saving Changes...
Mark Price PerryBusiness Driven PMO Evangelist| BOT InternationalOrlando, Fl, United States
Dear Dennis, great post and topic that can never really by beaten to death. We see many organizations that prefer in their SDLC to have a use case template in addition to, rather than incorporated into, the business requirement template. There is some value in having two distinct outputs. For example, they may be completed at different times and by different people in the organization. Likewise, you might wish to have an SDLC phase exit to review and approve the business requirements and use case documents prior to engaging in the next phase of the SDLC, typically a further requirements definition in more detail. The idea is that this level of detailed requirements analysis should not be performed (nor the time and cost incurred) until the higher level of business requirements has been reviewed and approved by management. In a similar fashion, you might not want to commit time, resource and cost to the Functional Design step of your SDLC until the detailed requirements analysis has been reviewed and approved by management. This may sound a bit bureacratic, but it is not at all really. In fact, if you have a look at the ITGI Control Objectives for Sarbanes Oxley, figures 11-15, you will see some very specific guidelines that are required of your SDLC in order to be SOX compliant. If your firm is a public company, you might want to review your SDLC with your SOX auditors if they haven't found you already. Hope this helps, I would be delighted to chat further. Best regards. -- Mark Perry, VP of Customer Care, BOT International Saving Changes...
My own view is that you seem to be taking the wrong approach entirely.
Life has moved way beyond the days when people would mandate the SDLC and prescribe the products/deliverables from projects.
You and Mark are having a conversation in abstract about what should come out of projects in terms of deliveables - but remember EVERY project is UNIQUE and it is up to the PM to decide what to produce BASED ON THE UNIQUE CIRCUMSTANCES OF THE INDIVIDUAL PROJECT. As for Mark's comments about SOX - remember this: in most organisations (and despite appearances to the contrary) SOX compliance is purely "ritual" ie lip-service is paid. Stop thinking like a petty bureaucrat and you might get somewhere. Saving Changes...
Mark Price PerryBusiness Driven PMO Evangelist| BOT InternationalOrlando, Fl, United States
Dear Paul, you raise an excellent point. Every project is unique and the PM must have the requisite PM skill sets to decide what to produce and how to produce it. I still remain Deming inspired and advocate commitment to processes and continuous improvement as the means to enable PMs to exhibit, share, and continually grow the very skills you mentioned. You are quite right and I agree with you that many organziations have moved beyond mandating a single methodology such as an SDLC. We see these organizations establishing IT processes and internal controls and enterprise-wide processes and best practices such as Governance, Portfolio Management, Project Management, SDLC, Change Management to name a few. In fact, with respect to SDLC we see that many organizations are seeking to have traditional SDLC models for enterprise applications and large scale projects such as ERP, CRM, etc. and lighter weight SDLC models for interative and rapid application development for less complex, shorter term SW development projects. Agile models such as XP, ASM, FDD, Scrum, Crystal and others are increasingly being adopted with good results. I particularly like Scrum. I suspect that this, defining their SDLC process, is what Mr. Davis is invloved with at his company as well. Regarding your comment about SOX compliance being purely ritual, ie lip service, I tend to disagree with you just a bit. You might be right in that some organizations, at present, may be paying lip service to SOX, but we are seeing that most organizations are very serious about understanding and complying with SOX. SOX is far more than a program du jour, credential to be obtained, or new fad of the management pundits and gurus. No doubt the auditor and vendor community has been off to the races perhaps creating more buzz and confusion than needed, but SOX is the law and for good reason. You might want to read up on sentencing guidelines for failure to comply with the US Sarbanes-Oxley Act of 2002 before getting on the elevator with your CEO or CFO. I can assure you, that to them, SOX compliance is not lip service. Cheers. -- Mark Perry, VP of Customer Care, BOT International Saving Changes...
I am with Paul Slade on this. Have you missed the point? Creating even more lifecycles is NOT the answer! Ever heard the expression "if you give boy a hammer every problem becomes a nail"? Well I think you might have fallen into this trap.
As for organisations being "very serious about understanding and complying with SOX"…. are you kidding? I don’t think you are talking about the real world..... organisations are serious about BEING SEEN to be compliant and most importantly getting the ticks in the boxes. They are NOT interested in actually doing the work required to genuinely comply with the "spirit" of the legislation. I would guess this is what Paul probably meant by "ritual" compliance.
" ... - but remember EVERY project is UNIQUE and it is up to the PM to decide what to produce BASED ON THE UNIQUE CIRCUMSTANCES OF THE INDIVIDUAL PROJECT"
I'm not sure how to review this. While every project is building a unique service or product there are similarities in developing products that must be considered. Are you saying that it should up to the PM to determine the deliverables needed and the methods to complete them?
If so, there is little documentation or research that supports that approach. Anecdotally I've seen that approach fail at a rate of about 30%-50% of projects executed using it. There is no single source of PM training I've found that, given a complex enough product, could prepare a PM for:
Managing a project with a unique product
Designing a process for managing the project
Determining the method to develop the products
Add to that the necessary industry knowledge and you create a job description that cannot be scaled.
In your and Eric's posts there is obvious energy towards standard corporate compliance efforts, process development, and the PMI. The original poster's questions were directed to how do I help my company create a productive, efficient, reliable product development capability through templates and standardized deliverable descriptions. Can you describe how you work to achieve that or if that approach is wrong how you avoid the standard project failure rates associated with companies that don't use standard process and methods to achieve results?
Dennis Wrote: 1. Shouldn't the use cases in the truest sense, be part of the bus. reqs template since its a method of gathering functional reqs? 2. If I do re-buld the bus req template to incorporate use cases, is there a real need for a functional spec?
Generally people aren't used to developing use cases. I've found this especially marketing or business folks. They tend to think in terms of product features. The use cases are generally treated with an "I’ll know it when I see it" attitude. So I recommend keeping the Use Cases as a response to the requirements document. Use cases should illustrate how the product will flow. I find it best if they are developed in conjunction with the Architecture. NOTE: I've found that there are almost always limits on the architecture, which will impact the use cases.
The architecture and use-cases can be reviewed in the context of the business requirements document. These three documents serve as a useful product road map. The specification of the product should be much more detailed. I've found that the spec goes through less revision when these documents are completed and agreed to by the stakeholders.
Saving Changes...
Mark Price PerryBusiness Driven PMO Evangelist| BOT InternationalOrlando, Fl, United States
Dear Eric, as often is the case, I suspect that we have more in common than our posts suggest and I don't think any of us have missed the point..! I do understand and appreciate your perspective. Mine is a little different, that's all. I hope to hear and learn from others as well. Cheers. -- Mark Perry, VP of Customer Care, BOT International Saving Changes...
Eric, as a CIO I can tell you that commitment to and participation in an organization's processes and best practices is what ensures best in class execution as well as separates the high-performers from others in the organization. Those (organizations and individuals) not committed to process and continuous improvement will be out competed. Saving Changes...
Anonymous
Eric, I agree with David Kester's points and would be interested in your response. You seem to be anti-process, anti-project management, and anti-management. What is your prescribed approach? Ad hoc? or wish upon a star? And how do you intend to improve and scale your approach? By way of collective meditation? And how do you intend to have your approach become the world's de facto standard? By calling organizations and people names? Or suggest that they don't live in the real world? Where I come from, one that resorts to name calling is one that has lost the debate. Saving Changes...
Anonymous, give me time to compose a reply to Mark/David! I do have a day job too – successfully delivering projects. By the way, in my thinking it is people who are afraid to use their names and who post anonymously who have lost the argument! If my tone doesn’t appeal to you too bad, I read this board and others like it and have to suffer reading the ludicrous unsupported claims and opinions make by posters most of which generally seem to be devoid of any critical thinking or basis in fact or academic literature. Also generally these boards as a whole seem to lack any critique and instead seem to have descended into some kind of dumbed down “group think”. I am offering some insight and bite as a badly needed antidote (and I wont even charge you for it). By the way, what makes you think I want to define “the world’s defacto standard”? Where did you get that idea from? Finally on re-reading there is no name calling that I can see – what names are you referring to exactly? If it is my tone you don’t like then you are being something of a hypocrite by posting the remarks “wish upon a star?” and “collective meditation?”!!!! In the meantime to get an idea of my position read my blog and posts.
Ruth, if you want to venture any facts or arguments rather than just bald unsupported opinions, I might consider a substantive reply. If your statement that you are a CIO is supposed to lend weight to your claims……it doesn’t.
Now having said that, lets head off any polemic. it is not my intention to be a troll or to flame, but PM and those currently blabbing on about it desperately need a rocket up their ***.
I am NOT “anti-process, anti-project management, and anti-management”. Being against McDonalds isn’t being anti-food, just anti-poor-quality-food. So yes I am anti-POOR-QUALITY-thinking about process, project management, and management. PMBOK SDLCs and PMI are as bad for your brain and your PM practice as McDonalds is for your arteries and your waistline.
Why do I think the PMBOK and espoused approaches of PMI are based in poor quality thinking? Well 20 years experience of doing projects and working in the PM field, but more importantly for this post the HUGE literature which goes back, even as far as the Greeks and ancient eastern thinking that shows how competent practical action in situations as complex as projects cannot be codified in prescriptive guidance such as SDLCs or PMBOK.
Taking David’s question: “Are you saying that it should (be) up to the PM to determine the deliverables needed and the methods to complete them?” Yes, yes yes a million times YES!
Each project is unique and competent action is based on responding to the situation at hand and acting in a way which is relevant to that situation, CATEGORICALLY NOT following the lifecycle or techniques in some “best practice” which can only lead to incompetent action.
To develop competent project managers we need to develop individuals who can draw on their own experience and intelligence to assess the project situation and then respond appropriately based on their education/training and their ongoing EXPERIENCE and inventiveness, not attempt to fall back on SDLC type “best practice”. Competent masterful performance is rooted in experience and a wide knowledge not the type of technocratic practice envisaged within prescriptive processes. As Ken Swaber and Mike Beedle put it: the mistaken belief is that PM’s are dealing with a” Defined” process when in fact they are actually facing an “Empirical” process. See here for more.
By the way although these two guys are talking about SDLC their ideas apply equally well to project management. If interested, see in particular this section: page 5 para2 starting “I wanted to understand the reasons that my customer methodologies didn’t work” down to the end of the page.
Since Swaber and Beedle do such a good job of making the point I don’t think I need to say any more on the subject of poor quality thinking about process, project management, and management, such as that in SDLC’s and the PMBOK, even although there are a dozens of other equally valid arguments firmly rooted in high quality academic literature which could demolish the PMI, SDLCs and PMBOK!
PS. The reason that I am so heated up about this issue at the moment is that my current organisation is being invaded by the type of bureaucratic morons who peddle SDLCs and PMBOK type snake-oil, as usual gullible senior management are in danger of being taken in and the end result is predictable - wasted time & money not to mention huge opportunity cost while projects get bogged down in PMI/PMP nonsense.
