SylvanoMTL said:

I have tried to share the spreadsheets that contains the requirements, but this is always ignored.

It strikes me that this is your real problem.  People can ignore your requirements however you present them.

When it comes down to it, DOORS can be considered a glorified spreadsheet.  It's linking and filtering abilities are probably better, but you're still turning your requirements into a big table.

Totally agree with Simon. For small projects (and I'm involved in very serious safety critical projects) I find Word or Excel absolutely fine. The clever bit is more the way you approach the requirements.

Key is ensuring that the requirements (however they are managed) cover the following:

• A unique requirement number.
• A precise definition of the requirement, the test being whether it will be clear what the evidence will need to be to show that the requirement has been met.
• The rationale for the requirement, what will happen if the requirement is not met. This becomes important both to support chasing requirements and for those cases where requirements don't get met and the risk needs to be justified of leaving them (permanently or temporarily) as outstanding / cancelled.
• The owner of the requirement. Really important, this is the person who has overall responsibility and accountability for the requirements being / not being managed. And if the requirement doesn't get managed, the person who takes responsibility for justifying that. Back to the post, the person who has the problem of chasing these requirements to get closed. This needs to be at the appropriate level of seniority, which may be your problem.
• The status of the requirement, e.g. in preparation (wording being agreed), in progress (engineering being carried out to meet the requirement), closed (evidence provided that requirement has been met), transferred (decided that this requirement is the responsibility of another project), or cancelled (deemed as no longer required).
• For very formal processes, evidence that that the requirement has ben met e.g. a reference to test evidence

So you can see how a simple Excel sheet can manage this, with a simple filter on the "status" column giving you the key project control information of which are your outstanding requirements. Which you can then bring up again and again at each project meeting...

DOORS is useful where you have a huge number of requirements across a project with many subprojects, maybe running over several years, and you want many different views of this, and links to sources and evidence etc. But as Simon says, it doesn't make anyone comply with the requirements any more than a simple Excel sheet does. What I tend to use is a Word document to list the requirements in a formal Requirements Specification as it's easy for the engineering team to read, but Excel to track the requirements for management - I've set up the Excel template I use a lot (which includes a load of other stuff as well) to include a "Word friendly" sheet so it's very easy to cut and paste from this to update the Word version when I need to.

Hope that helps,

Thanks,

Andy 

I had a play with LibreOffice Calc last night.  Although it's very poorly documented, you can create hyperlinks between cells in one sheet to cells in another.  So if you created one sheet per document, you could add links between, say, a test plan and the requirements document that it needs to meet.

Hi Simon Barker  you could try looking at projectmanagement.com. 

www.projectmanagement.com/searchresult.cfm

The issue with not using a formal tool is that you introduce risk. The question you need to ask is if the cost of the potential risk outweighs the cost of using a formal tool. What would project failure mean to the organisation, whether that is a cost or timing overrun (which is the usual consequence of scope creep) or a lack of perceived quality which can often be the case if you have missed requirements.

There are other tools, and some are less expensive then DOORS (and some more).

It is also more important to have a rigorous process when you are using informal tools as the tool can make it easier to spot mistakes (but sometimes it helps you make mistakes faster, so the tool is not a solution in itself).

That said, its quite feasible to capture requirements in a word processor or a spreadsheet. Although the companies I have worked for have been using formal tools for some time, this has not always been the case with our customer and they have supplied the stakeholder requirements in a variety of formats. Despite the fact those customers were not using a formal tool, those projects did succeed.

I would say that items (1) to (4) above are about your process and are completely tool agnostic. (5) you will only find with the big tools I'm afraid, and usually part of an entire PLM tool set. However, by being consistent with naming you can tie a project plan to a requirements set, its just the checks to make sure it matches is manual.

If you have smaller projects and its a challenge to elicit the requirements, sometimes the model based systems engineering (MBSE) practices are useful. But those are not something you learn overnight.

Regards,

Mark

Projects need to be planned and costed well in advance and site checked for possible defects or problem areas to eliminate risk.

First write an introductory paragraph on project with expected results and its uses in the future to the owner.

Stress that all work and materials used must be in compliance with accepted international specifications and standards and quote any that are particularly important to your project.

Next prepare the drawings of overall project showing as much detail on an Ordinance Survey plan + items as possible

Then mark on all critical information as to orientation of structure, special materials marked on in text clouds.

THIS PLAN IS CONTRACTUALLY CRITICAL AND MUST BE TOTALLY CORRECT IN EVERY DETAIL

Prepare a bill of quantities, their costs, delivery and order time + costs

Main Contractor to issue a schedule of work with key benchmark dates including start and finish dates

Draw up terms and conditions of contract  "The elements of a contract include identification of scope of works, offer, acceptance, consideration, competency and capacity, and contract legality."  Fidic is used for large contracts and included clauses for extras or delays and cancellation procedures 

I struggle to see the relevance of this comment to the original post especially as that refers to an internal project and not one using external contractors.

However, the concept of a good plan and cost model is very valid.

While gathering the requirements from your internal stakeholders and reporting their status along the project is very important, it looks like the real difficulty is to make the internal customer aware of the choice/recommendations and the implications they have.

Perhaps, it would help to call some formal meeting with the internal stakeholders and some senior managers sponsoring the project ,typically whoever is responsible to grant the money to the project, so as to ensure there is agreement on the steps and direction to take.

I suggest:

• A first formal meeting at project start, when you give the outlook of what is being required, the difficulties you have identified, the resources you need  and the schedule to implement the project
• A second formal meeting when you have a clear recommendation on how to solve the difficulties you identified and the money you are going to spend. This signals a point of no return to your internal customers and sponsor
• A third formal meeting when you implemented the project and know how it performs, prior to making it live of in production. This is to ensure the quality level and other key performance parameters are accepted by your internal customers and sponsor
• A forth formal meeting after the project has been running for some time to close it, release resources still allocated, share lesson learned and give recommendations.

Try out this additional communication method with your customers and sponsor and hopefully changes will be reduced. After all, it doesn't cost a lot of money though for sure you need to use some of your time to organise and hold these meetings.

I hope that, by now, you have realised your problem isn't the lack of a tool but it's the lack of a process.I don't know how much experience you have in project management so forgive me if this is too basic.

Reading between the lines of your post it looks as though you have found yourself managing projects in an organisation that doesn't run projects with any formality. I suggest you take an afternoon to write yourself a simple project lifecycle. The post by Gianni Cessel below is a good start. Change it to reflect your organisation and the people with whom you will be working. Write up the lifecycle as a presentation and then run it past a few trusted colleagues for comments an feedback. Don't forget to include a simple requirements process and also a project change process. Then walk to talk - start to manage your projects according to your lifecycle. You'll be surprised how others will soon fall in line.

I would recommend you buy a copy of the Guide to the Project Management Body of Knowledge (PMBOK (R) Guide) (PMBOK® Guide) It's on Amazon (UK) for about £37 and will give you plenty of ideas. It's a bit dry but don't let that put you off.

Software tools are just a way of making processed tangible and as has been pointed out spreadsheets, documents and presentations are a much simpler way to go. However, if you really want a software tool, take a look at Redmine (https://www.redmine.org/) You'll need a PC or small server to host it. You'll also have to configure it to suit your needs but it is free.

Hi all, 

thank you for your replies. I am fully aware the main issue is the lack of process in my company. On many aspects I would say. I am not here to bash on my employer who hired me couple of months ago. I know the main issue is that people expect miracles without following best practice. This is due to that there has been minimal investment in many aspects of the business. Most of the staff is either not technical, or operating as test technicians. They need replacement parts on systems that fails, they need a new measurement instrument but they have no clue on the physics involved (optic/acoustic/vibration/shock/temperature...). They just need something that look like what they have at the moment. Their criteria are not defined. It is also difficult to schedule meetings them, for more than 30mins.

I have already made some spreadsheets to capture the systems requirements. As some of you mentioned, one issue is that this is ignored. And the cause is that no one has really been educated to this. I think it will come with time but I have flagged two other issues with spreadsheets: 

1) lack of formalism in regard to how you capture the requirements, which enable ways to write them wrongly : e.g. I can ask a technician to review the requirements I drafted based on the conversation we have in the lab. And he may add: "there  should be a way to fix this device to this support using a plastic or ss bracket", rather than: "the device shall be mounted on the system using a bracket" and "the mounting bracket shall not corrode while the system is in operation"
If there was a tool to avoid to write multiple requirements in one, that would be ideal.

2) Spreadsheets are messy, not fault proof and hard to maintain.
   Anyone who did a bit of oriented object may understand what I mean. Or anyone who deleted a column in Excel which was link to some formulae will concur with me. Also any improvement of the spreadsheet is generally undocumented, and hard to implement for all other project spreadsheets.
One main issue I have had was numbering requirements, or reordering them. 


Through my research, I found a file format call reqIF. I will have a deeper look at it. It seems that Eclipse has something call ProR to edit such files (https://www.reqif.academy/library/books/handbook/?p=sec-rmf_derivatives.html). This is something I might explore in the future. 

For other aspects of project planning, I have now access to MS projects, and I am self-training on it. 

PS: Not so satirical, but I joined as an electromechanical engineer, I was given a desk, a laptop and solder iron. trackability of legacy projects from my predecessor was inexistent, and I am still running in the labs after screwdrivers .